Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mark David Dumlao <madumlao@gmail.com>]

On Tue, Feb 18, 2014 at 3:53 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 17/02/2014 17:29, Stroller wrote:
>>
>> On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>> ...
>>> Whatever problems Red Hat are trying to solve in the Red Hat space are
>>> problems that do not affect me, so I do not need Red Hat's solution. As
>>> for Gnome, I have yet to see a valid reason why Gnome *must* use
>>> systemd; that is simply not true at all.
>>
>> I thought this all boiled down to "trying to login to GDM using accessibility functions and a bluetooth hearing aid" (or bluetooth keyboard, for that matter).
>
> That was the classic rationale for "no separate /usr without an initrd"
> in udev - the claimed need to have any arbitrary runnable code available
> to be run before the entire system is up and running.
>
> Red Hat's reasons for pushing systemd are more fuzzy and nothing I've
> read so far tells me we have the full picture. Two things seem highly
> plausible:
>
> 1. An init system that can use modern features of the Linux kernel (most
> often Linux-only at this point) like cgroups
> 2. Extremely fast boot times to spin up virtual machines in a fraction
> of the time it currently takes.
>
> #1 may or may not be desirable, I honestly don't know. What I have seen
> is a lot of theory and not much reproducable fact.

init scripts, in general, are ad-hoc, quirky, and incomplete
implementations of service supervision in bash. They're reliable so
long as the daemon can be relied on to advertise one or all of its
processes in a pid file. Thing is, there are way too many different
possible setups for services for that to be the case. In the average
case watching a PID file works. And since most people use "average
software", most people don't care. That's ok.

Thing is an init isn't just for "most people". It's for "all people".
It should be reliable for all services.

I used to use cherokee. Fast, light, awesome, and with a web admin.
The init script always failed me. /etc/init.d/cherokee stop was not a
guaranteed stop to all forked cherokee processes - the parent pid
dies, but some forked process or something, usually related to
rrdtool, doesn't. Or the parent does exit and erases the pid file but
it returns control immediately and its not yet done exiting. Something
like that or other. Point is, I've several times had to ps aux|grep
... kill; zap; start - on production servers.

Was it cherokee's fault? Maybe. But the init script should have told
me that. Or even better, the init script should have done its job and
terminted the processes. See, pid files are just a proxy, they don't
work for all services and all setups. Maybe a process crashes before
it kills its forks. Maybe the server has a restart feature that fails
to write the pid file because the init script created it as root but
the daemon relinquished privileges. Maybe there's a bug somewhere.
Maybe the pid file gets overwritten accidentally. Maybe the pid file
is stale because of a power failure. Point is you don't know until the
service restart which should "just take a sec" costs you maybe an hour
or two in billable time.

With supervised cgroups that's not a problem. Because all process
forks are grouped together, it doesn't matter if there's a pid file or
not. When its kill time, the daemon and all forks and children go
down. Because they're dynamically created on start, they don't get
stale or point to the wrong process. Sounds to me like the right tool
for the job.

The init script introduces a point of fragility and brittleness into
the system making it harder to debug, all to implement service
supervision. If you look at the upstream docs of your daemon, it'll
probably just tell you to run /usr/sbin/somethingd, maybe with a -d
argument, to find out why it isn't starting. Cue the init script now
always failing because you just created a bunch of files as the root
user. Bit me in the back a few times with mysqld. Oh, I'm supposed to
read the whole init script to determine all environment variables,
settings, and switches the system uses to start a daemon, right? Good
luck grepping. Because from a unit file, I can tell the command to run
in a single glance.
-- 
This email is:    [ ] actionable   [x] fyi        [ ] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none