[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pid file security



On Sat, Jun 5, 2010 at 7:59 AM, Luke Kenneth Casson Leighton
<luke.leighton@gmail.com> wrote:
>  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:

http://0pointer.de/blog/projects/systemd.html


Reply to: