Bug#727708: upstart proposed policy in Debian [and 1 more messages]
On Sat, 2013-12-21 at 08:49 -0800, Russ Allbery wrote:
> Tollef Fog Heen <tfheen@err.no> writes:
> > sd-daemon.c is also intentionally designed to not have dependencies on
> > the rest of the systemd source and to be portable to non-linux
> > architectures too (but basically just stubs then) just so people can put
> > the file in their source and not have to fiddle with checking for
> > libraries and such if they find that tedious.
>
> I agree with Ian's dislike of this approach. We try to avoid embedded
> code copies, and I'm not sure why this would be an exception. Yes, the
> code is fairly simple and hopefully doesn't contain (for example) security
> vulnerabilities, but it's possible to find bugs in just about anything.
> Updating numerous copies of that code is not appealing.
I don't see why that should be considered a particularly significant
downside though. Copies are usually worse than shared code, but not
really worse than everything having a custom implementation. At least
implementing sd_notify() support with a code copy should be considered a
significant improvement over a daemon that always runs custom
double-forking code.
BTW it's worth noting that in the typical daemon case where "readiness"
means the listening socket is ready to accept requests, the right way to
convert the daemon to a new API is to use socket activation, which
removes the need for separate start-up completion notification. Thus the
need to use sd_notify() for this purpose should be the exception rather
than the rule. This means that daemons which would use libsystemd-daemon
for startup notification and nothing else (and would thus be potential
candidates to abuse SIGSTOP) should be rare.
Reply to: