On Tue, Feb 18, 2014 at 3:53 AM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > On 17/02/2014 17:29, Stroller wrote: >> >> On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon >> <alan.mckin...@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
