| 1 |
On 18/02/2014 05:46, Mark David Dumlao wrote: |
| 2 |
> On Tue, Feb 18, 2014 at 3:53 AM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
| 3 |
>> > On 17/02/2014 17:29, Stroller wrote: |
| 4 |
>>> >> |
| 5 |
>>> >> On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
| 6 |
>>>> >>> ... |
| 7 |
>>>> >>> Whatever problems Red Hat are trying to solve in the Red Hat space are |
| 8 |
>>>> >>> problems that do not affect me, so I do not need Red Hat's solution. As |
| 9 |
>>>> >>> for Gnome, I have yet to see a valid reason why Gnome *must* use |
| 10 |
>>>> >>> systemd; that is simply not true at all. |
| 11 |
>>> >> |
| 12 |
>>> >> 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). |
| 13 |
>> > |
| 14 |
>> > That was the classic rationale for "no separate /usr without an initrd" |
| 15 |
>> > in udev - the claimed need to have any arbitrary runnable code available |
| 16 |
>> > to be run before the entire system is up and running. |
| 17 |
>> > |
| 18 |
>> > Red Hat's reasons for pushing systemd are more fuzzy and nothing I've |
| 19 |
>> > read so far tells me we have the full picture. Two things seem highly |
| 20 |
>> > plausible: |
| 21 |
>> > |
| 22 |
>> > 1. An init system that can use modern features of the Linux kernel (most |
| 23 |
>> > often Linux-only at this point) like cgroups |
| 24 |
>> > 2. Extremely fast boot times to spin up virtual machines in a fraction |
| 25 |
>> > of the time it currently takes. |
| 26 |
>> > |
| 27 |
>> > #1 may or may not be desirable, I honestly don't know. What I have seen |
| 28 |
>> > is a lot of theory and not much reproducable fact. |
| 29 |
> init scripts, in general, are ad-hoc, quirky, and incomplete |
| 30 |
> implementations of service supervision in bash. They're reliable so |
| 31 |
> long as the daemon can be relied on to advertise one or all of its |
| 32 |
> processes in a pid file. Thing is, there are way too many different |
| 33 |
> possible setups for services for that to be the case. In the average |
| 34 |
> case watching a PID file works. And since most people use "average |
| 35 |
> software", most people don't care. That's ok. |
| 36 |
> |
| 37 |
> Thing is an init isn't just for "most people". It's for "all people". |
| 38 |
> It should be reliable for all services. |
| 39 |
> |
| 40 |
> I used to use cherokee. Fast, light, awesome, and with a web admin. |
| 41 |
> The init script always failed me. /etc/init.d/cherokee stop was not a |
| 42 |
> guaranteed stop to all forked cherokee processes - the parent pid |
| 43 |
> dies, but some forked process or something, usually related to |
| 44 |
> rrdtool, doesn't. Or the parent does exit and erases the pid file but |
| 45 |
> it returns control immediately and its not yet done exiting. Something |
| 46 |
> like that or other. Point is, I've several times had to ps aux|grep |
| 47 |
> ... kill; zap; start - on production servers. |
| 48 |
|
| 49 |
|
| 50 |
Valid point. Other than vixie-cron (damn thing just never seems to die |
| 51 |
properly on any platform so restarts always fail) I don't really run |
| 52 |
into these issues |
| 53 |
|
| 54 |
What I do run into is daemons that drop privs on start up, like |
| 55 |
tac_plus. Unwary new sysadmins always try start/stop it as root, causing |
| 56 |
an unholy mess. Root the owns the log and pid files, when tac_plus drops |
| 57 |
privs it can't record it's state so continues to service requests but |
| 58 |
fails to log any of them. For an auth daemon, that's a serious issue. |
| 59 |
|
| 60 |
|
| 61 |
-- |
| 62 |
Alan McKinnon |
| 63 |
alan.mckinnon@×××××.com |
Archives