6 ms·

yeah, many options that are complicated beyond the understanding of the distro maintainers, and yet still don't allow expression of common semantics required to

by blibble 8mo ago

yeah, many options that are complicated beyond the understanding of the distro maintainers, and yet still don't allow expression of common semantics required to support network services reliably like "at least one real IP address is available" or "time has been synced" and it's not esoteric, even ListenAddress with sshd doesn't even work reliably the ONLY piece of systemd I've not had problems with is systemd-boot, and then it turned out they didn't write that

jorvi 8mo ago
> like "at least one real IP address is available" or "time has been synced" "network-online.target is a target that actively waits until the network is “up”, where the definition of “up” is defined by the network management software. Usually it indicates a configured, routable IP address of some kind. Its primary purpose is to actively delay activation of services until the network has been set up." For time sync checks, I assume one of the targets available will effectively mean a time sync has happened. Or you can do something with ExecStartPre. You could run a shell command that checks for the most recent time sync or forces one.
- bandrami 8mo ago
  Sysadmins really hate the word "usually", and that is at the root of just about every systemd headache I've had
- direwolf20 8mo ago
  Is it possible for network-online to mean that, or does network-on actually mean that? It is possible for a specification to be so abstract that it's useless.
  - jcgl 8mo ago
    That's entirely defined by whatever units order themselves before network-online.target (normally a network management daemon like NetworkManager or systemd-networkd). systemd itself doesn't define the details; that's left up to how that distro and sysadmin have configured the network manager/system.
- blibble 8mo ago
  it's the "usually" that's the problem this service (untouched by me) had: After=local-fs.target network-online.target remote-fs.target time-sync.target but it was still started without an IP address, and then failed to bind just like this sort of problem: https://github.com/systemd/systemd/issues/4880#issuecomment-267150503 https://github.com/systemd/systemd/issues/4880#issuecomment-... the entire thing is unreliable and doesn't act like you'd expect > Or you can do something with ExecStartPre. You could run a shell command that checks for the most recent time sync or forces one. at that point I might as well go back to init=/etc/rc
  - deleted 8mo ago
    [deleted]
  - jorvi 8mo ago
    Are you running this particular unit file as a user unit or a system unit? Some targets like network-online.target don't work from user unit files. You could also try targeting NetworkManager or networkd's "wait-online" services. Or if that doesn't work, something is telling systemd that you have an IP when you don't. NetworkManager has "ipv4.may-fail" and "ipv6.may-fail" that might be errenously true. > at that point I might as well go back to init=/etc/rc The difference is that systemd is much better at ensuring correctness. If you write the invoked shell command properly, it'll communicate failure or success correct and systemd will then communicate that state to the unit. It's still a lot more robust than before.
    - blibble 8mo ago
      it's a system service file the problem is systemd > The difference is that systemd is much better at ensuring correctness. yeah, whatever mate
      - jorvi 8mo ago
        Seems like you have an axe to grind with systemd because it replaced your familiar (but extremely cruddy) init system and now you refuse to debug the problem because you prefer being able to blame systemd. There is so much granularity and flexibility in what you can do it seems rather unlikely you cannot make it happen correctly. And if it is truly a bug... open an issue? They're rather responsive to it. And it isn't like the legacy init systems were bug free from inception (well, lord knows they were still chock full of bugs even when they were replaced). Edit: sitting here with a grin .. HN downvoting the advice of checking logs, debugging and opening an issue. I wish the companies y'all work at good luck.. they'll need it.

by blibble 8mo ago

jorvi 8mo ago

> like "at least one real IP address is available" or "time has been synced" "network-online.target is a target that actively waits until the network is “up”, where the definition of “up” is defined by the network management software. Usually it indicates a configured, routable IP address of some kind. Its primary purpose is to actively delay activation of services until the network has been set up." For time sync checks, I assume one of the targets available will effectively mean a time sync has happened. Or you can do something with ExecStartPre. You could run a shell command that checks for the most recent time sync or forces one.

bandrami 8mo ago
Sysadmins really hate the word "usually", and that is at the root of just about every systemd headache I've had
direwolf20 8mo ago
Is it possible for network-online to mean that, or does network-on actually mean that? It is possible for a specification to be so abstract that it's useless.
- jcgl 8mo ago
  That's entirely defined by whatever units order themselves before network-online.target (normally a network management daemon like NetworkManager or systemd-networkd). systemd itself doesn't define the details; that's left up to how that distro and sysadmin have configured the network manager/system.
blibble 8mo ago
it's the "usually" that's the problem this service (untouched by me) had: After=local-fs.target network-online.target remote-fs.target time-sync.target but it was still started without an IP address, and then failed to bind just like this sort of problem: https://github.com/systemd/systemd/issues/4880#issuecomment-267150503 https://github.com/systemd/systemd/issues/4880#issuecomment-... the entire thing is unreliable and doesn't act like you'd expect > Or you can do something with ExecStartPre. You could run a shell command that checks for the most recent time sync or forces one. at that point I might as well go back to init=/etc/rc
- deleted 8mo ago
  [deleted]
- jorvi 8mo ago
  Are you running this particular unit file as a user unit or a system unit? Some targets like network-online.target don't work from user unit files. You could also try targeting NetworkManager or networkd's "wait-online" services. Or if that doesn't work, something is telling systemd that you have an IP when you don't. NetworkManager has "ipv4.may-fail" and "ipv6.may-fail" that might be errenously true. > at that point I might as well go back to init=/etc/rc The difference is that systemd is much better at ensuring correctness. If you write the invoked shell command properly, it'll communicate failure or success correct and systemd will then communicate that state to the unit. It's still a lot more robust than before.
  - blibble 8mo ago
    it's a system service file the problem is systemd > The difference is that systemd is much better at ensuring correctness. yeah, whatever mate
    - jorvi 8mo ago
      Seems like you have an axe to grind with systemd because it replaced your familiar (but extremely cruddy) init system and now you refuse to debug the problem because you prefer being able to blame systemd. There is so much granularity and flexibility in what you can do it seems rather unlikely you cannot make it happen correctly. And if it is truly a bug... open an issue? They're rather responsive to it. And it isn't like the legacy init systems were bug free from inception (well, lord knows they were still chock full of bugs even when they were replaced). Edit: sitting here with a grin .. HN downvoting the advice of checking logs, debugging and opening an issue. I wish the companies y'all work at good luck.. they'll need it.