Uoti Urpala <uoti.urp...@pp1.inet.fi> writes: > Does sd_notify() actually give any positive effect compared to just > using type=simple, given that you already have socket activation? The > UDP socket should buffer packets until the daemon reads them. Explicit > notify does have the negative effect that depending services can not be > started in parallel.
> Or do you want to support running it as a systemd service but without > using socket activation (would seem rather pointless)? You ship a > .socket file by default, so it doesn't explain the use of type=notify in > the provided file at least. The thought was the latter, combined with the intent to fully explore the whole systemd interface. Also, there are situations where I believe that systemd will start the service without using socket activation even when socket activation is configured. For example, if I disable both lbcd and lbcd.socket, and then manually start lbcd.service, lbcd.socket is not started, which I suspect means that socket activation is not used. None of those are particularly important, and I suspect that using socket activation is sufficient and synchronization isn't actually needed. That said, I see no drawback to adding the sd_notify call to the upstream source; if people don't want to use socket activation, they can disable it in the unit file, and this way they don't have to use socket activation if they don't want to for some reason. The code is so trivial to add (particularly if one is already using socket activation) that there doesn't seem to be a reason not to do it. Your point about depending services is a good one, though, and if this service is the sort of thing that anything else was likely to depend on, it would probably be better to just use socket activation with no synchronization if socket setup was all that was required. Maybe I should just do that anyway; I'm probably reaching too hard for cases where the socket wouldn't be enabled. > I think the .service file should have a Requires= on the socket to make > the service fail in case the socket could not be opened (probably > doesn't matter otherwise). I think I misunderstood something I read in systemd.service(5) and thought it said not to do that, but it was talking about something different. That would probably also get rid of the case that I mentioned above. However, daemon(7) does say: It is recommended to place a WantedBy=sockets.target directive in the [Install] section, to automatically add such a dependency on installation of a socket unit. Unless DefaultDependencies=no is set the necessary ordering dependencies are implicitly created for all socket units. For more information about sockets.target see systemd.special(7). It is not necessary or recommended to place any additional dependencies on socket units (for example from multi-user.target or suchlike) when one is installed in sockets.target. I'm not entirely sure whether "any additional dependencies on socket units" is meant to imply that lbcd.service should not depend on lbcd.socket, or if that's just talking about the [Install] section of the socket file itself. Hm, reading daemon(7), I did mention this part: Usually you also want to make sure that when your service is installed your socket is installed too, hence add Also=foo.socket in your service file foo.service, for a hypothetical program foo. I'll fix that, and that would also get rid of being able to independently enable or disable lbcd.service from lbcd.socket. > There's a typo "mutli-user.target". Huh, yes, indeed... ah, I see what happened. I got this right when testing and then made a typo in the file in the package, so this was working on my test system. Bleh. I'll fix this in the Debian package. (I hate it when I upload four versions of a package within a day because I keep missing things.) Shouldn't there be a warning somewhere if a unit file specifies WantedBy on a target for which there's no *.target configuration installed? Or is this intentional to allow systemd units written for other systems with different target naming conventions to be installed without trouble? (Still, some sort of lint program would be useful.) Thank you! -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org