Thanks for the fix.
Maybe something to backport to 20.09?

Done: d6f95aa

Great, thanks!

After some more testing, I found out my server doesn't seem to have the network interface ready when ethtool is called, so I ended up using:

  systemd.services.wol-eth0 = {
    description = "Wake-on-LAN for eno1";
    requires = [ "network.target" ];
    after = [ "network.target" ];
    wantedBy = [ "multi-user.target" ];
    serviceConfig = {
      Type = "oneshot";
      ExecStart = "${pkgs.ethtool}/bin/ethtool -s eno1 wol g"; # magicpacket
    };
  };

Seems like the most logical moment to do it, since by definition the network is ready to go, so the interface must be too.
Not sure how to do it in the correct way for inclusion upstream though.

@magnetophon the problem with this simple systemd service is that if you use wol for wake from suspend, you need to run the command again after everytime the system gets out of suspend; which is something powerUpCommand does.

For the initial post-boot run, it is indeed run pretty early (at the end of bootStage2, before the main systemd kicks in with networking and everything) -- I've personally not had a problem with network not being ready, do you get an error or did you just notice wol is not actually enabled? That might be hardware/driver dependent, in which case an extra after network.target service might be good for safety... Better activate wol twice than none :|

Thanks for the heads up, I've un-commented my services.wakeonlan.interfaces again to make sure!

I indeed got an error.

Ideally we'd find a place to run it that covers both cases in one go, right?
Any ideas?

Do you still have the error for reference? (mostly curiosity on my part)

And I guess yes, ideally not reinvent the wheel by recreating two services ourselves, but I'm afraid I don't really know of a magic place that would cover both.
I guess the second best would be powerManagement.resumeCommands instaed of powerUpCommands (that only covers after-resume-from-sleep/hibernation/etc) plus an extra service after network like you've done, that will cover both usecases.

Although err now I'm looking at it again it doesn't have any wantedBy/requiredBy so I can't say I'm confident it actually works, would need testing somewhere that can suspend freely, I don't have anywhere to...

At this rate though it might be simpler to just define a systemd service like you did yourself and put it in multi-user.target after network.target and in wantedBy sleep.target after sleep.target; will need testing but that should work to just list both in after and wantedBy in a single service...

Thanks.

I didn't save the error and it'd be a bit of an expedition to get it again.
If it's mostly curiosity, I'd like to spare myself the hassle.

On the other hand, I would be more then happy to test any proposals for a solution that can be up-streamed.

Same here, it seems like the interface gets reset later on in the boot process.

My manual solution, but with a systemd link file:

  # enables wake on lan
  systemd.network.links."50-wol" = {
    enable = true;
    matchConfig = {
      MACAddress = "00:00:00:00:00:00";
    };
    linkConfig = {
      NamePolicy = "kernel database onboard slot path";
      MACAddressPolicy = "persistent";
      WakeOnLan = "magic";
    };
  };

Based on this here: https://wiki.archlinux.org/title/Wol#systemd.link

Using a link seems more reliable and only requires systemd-udev, which is always available.
It's worth considering to rewrite this module to use them.

The downside of this is that you need to know the mac address, a larger burden for the user who wants to enable it.
I tried using the name attribute as described in the arch wiki article, but it did not work.

That's true, but matching the interface by name isn't reliable. The standard kernel names (ie. eth0, eth1) tends to flip-flop across reboots and the systemd names (ie. ens1) change when adding new hardware or changing BIOS settings. To be really sure the name is stable you have to manually assign the name beforehand using a MAC address anyway.

If this is going to happen, maybe we should consider moving the wakeonlan option under interface, so e.g.

networking.interfaces.enp8s0.wol = {
  enable = true;
  # if set to anything then it's assumed as the prefered method
  password = "";
  # mac address only needed if networking.interfaces.name.macAdress is not set
  macAdress = "bla bla";
}

would by my preferred way of configuring it

Good idea: the current services.wakeonlan doesn't make much sense given the module doesn't set up a service.

I've looked into implementing this, and the mac option wouldn't be needed since the option in the interfaces is meant to override. And the only way how you can select interfaces is by name, which are assumed stable in newer kernels and udev/systemd releases.

One problem that I have faced tho is that it seems you cannot enable secureon for wol with the systemd link file, the option exists but I cannot figure out how to pass the specific password to systemd, the relevant code (judging by a quick glance) doesn't give any hints how to, so maybe it's not possible (read: a bug in systemd). https://man.archlinux.org/man/systemd.link.5

I made a quick mockup here: legendofmiracles@b8ea535, it works on my system.

But the password option doesn't work yet, due to the issues mentioned above.

But the password option doesn't work yet, due to the issues mentioned above.

I've opened an issue, let's see.

It's probably worth upstreaming my fork without the secure on support. I doubt anyone actually uses it (as shown by the fact that systend only had half assed support, but nobody complained). Waiting for the next systems release, if it even gets merged by then, is not really in my interest and the people having to manually setup wol due to it not working for them.

PR is here: #140779