Bug#727708: upstart and upgrading from sysvinit scripts
Uoti Urpala <uoti.urpala@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: