On 18/02/2014 05:46, Mark David Dumlao wrote: > 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.
Valid point. Other than vixie-cron (damn thing just never seems to die properly on any platform so restarts always fail) I don't really run into these issues What I do run into is daemons that drop privs on start up, like tac_plus. Unwary new sysadmins always try start/stop it as root, causing an unholy mess. Root the owns the log and pid files, when tac_plus drops privs it can't record it's state so continues to service requests but fails to log any of them. For an auth daemon, that's a serious issue. -- Alan McKinnon alan.mckin...@gmail.com
