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

[J. Roeleveld]

On Tue, February 18, 2014 12:54, Mark David Dumlao wrote:
> On Tue, Feb 18, 2014 at 5:52 PM, J. Roeleveld <joost@××××××××.org> wrote:
>> On Tue, February 18, 2014 10:47, Alan McKinnon wrote:
>>> On 18/02/2014 05:46, Mark David Dumlao wrote:
>>>> 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
>>
>> Interesting, I have never had issues with restarting vixie-cron using
>> the
>> supplied init-scripts.
>>
>>> 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.
>>
>> Shouldn't sysadmins use the init-scripts for that?
>> If done correctly, permissions should not be an issue.
>>
>> Restarting services without keeping file ownership into account will
>> always cause issues. Regardless of the init-system used.
>>
>
> That's just the thing though. As a sysadmin, how do you debug a service
> that isn't starting to begin with?

This isn't what Alan was talking about.
He was talking about restarting an existing, working service.

> Let's say your new to the service.
> You're
> not even sure if you got the config right the first time around. Or maybe
> you're adjusting a setting somewhere, and you're confused why it
> isn't taking effect.

In an environment where Alan works, I wouldn't be the only person around.
There should be someone on call who knows.

> All the /upstream documentation/, all the /man pages/, all the
> /usr/share/doc
> stuff will tell you to start it _raw_. The init script obscures the
> starting options,
> environment variables, and sometimes even the running user from you. What
> are
> you gonna do, play a human shell script parser? Nobody's perfect, do it
> enough times and you're going to casually gloss over the line where
> --safe-mode is appended to the string depending on the phase of
> the moon...
>
> If you're lucky, you've never had to start an unfamiliar service, or debug
> someone else's unfamiliar config under time pressure...

I have been on both ends of this.

I have multiple times been in a situation where I was under time-pressure
to get services running again on unfamiliar systems. Talking untrained
admins through the process by phone-communication only.
It is not easy, but by staying calm and focused, mistakes are avoided.
Also, in my experience, a calm systematic approach is usually faster then
the cowboy-method of trying everything I can find on Google.

I have also, too often, had to clean up the mess caused by these cowboy
tactics.

--
Joost