Re: pid file security
On Sat, Jun 5, 2010 at 7:59 AM, Luke Kenneth Casson Leighton
> okaaay, riight. so. ah ha. it makes things quicker... by avoiding
> starting the services _entirely_ :)
It goes beyond that. Instead of program A depending on B being done
initializing so that it can connect to B's socket, for example, A can
be initialized right away and it'll block when it needs to use B's
socket until B is done initializing. This is faster because A and B
can be started at the same time even though A depends on something
provided by B.
> second: assuming that systemd is _only_ capable of starting up
> services [as an inetd replacement] via redirecting stdin/stdout to
> TCP/UDP/other sockets, that still places depinit as being more capable
> than systemd because you have the option, in depinit, of:
> * running a service "unmonitored" i.e. a la sysv init
> * running a services "foreground-connected" i.e. auto-restarted etc.
Well, systemd does have sysv-like compatibility (in fact it even
parses LSB headers and starts sysv scripts in parallel, unlike
upstart). I believe that in that mode it does not monitor the
processes, but I'm not sure.
Now regarding auto-restarting services as they fail, I believe that's
at least planned. Since systemd can monitor services with ease, my
guess is that auto-restarting shouldn't be a big deal.
I'm quite excited about systemd, I think the potential is there. Most
mainstream distros have already commited to upstart though, so I can
see why it could fail despite looking like a great alternative.
Another major issue is lack of cross-platform support, as it depends
on Linux specifics such as cgroups, and this is a big drawback for
Debian as we have Hurd and kFreeBSD...
More info on systemd in this lengthy blog post: