Comment by blibble

Comment by blibble 5 days ago

18 replies

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 5 days 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.

  • blibble 5 days 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-...

    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

    • jorvi 5 days 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 5 days 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

      • direwolf20 5 days ago

        > Some targets like network-online.target don't work from user unit files.

        So basically it just doesn't work sometimes for no particular reason.

        > The difference is that systemd is much better at ensuring correctness

        Uh, well, you just said that it isn't, because some targets like network-online.target don't work from user unit files.

    • magicalhippo 5 days ago

      > https://github.com/systemd/systemd/issues/4880

      I'm not a systemd hater or anything, but I continue to read stuff from Poettering which to me is deeply disturbing given the programs he works on.

      Saying it's not a bug that service is launched despite a stated required prerequisite dependency failed... WTF?

      Sure, I agree with him that most computers should probably boot despite NTP being unable to sync. But proposing that the solution to that is breaking Requires is just wild to me.

      • jcgl 5 days ago

        I'm not sure I understand why you think the solution proposed there is so bad.

        The question in that issue is around the semantics of time-sync.target. Targets are synchronization points for the system and don't (afaik) generally make promises about the units that are ordered before them (in this case chrony-wait.service.

        Does that answer your specific objection of "proposing that the solution to that is breaking Requires is just wild to me"? Basically, what is proposed in that issue is not breaking Requires=. The proposition is that the user add their own, specific Requires= as a drop-in configuration since that's not a generally-applicable default.

    • [removed] 5 days ago
      [deleted]
  • direwolf20 5 days 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 5 days 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.

  • bandrami 5 days ago

    Sysadmins really hate the word "usually", and that is at the root of just about every systemd headache I've had