| 1 |
On Tue, Feb 18, 2014 at 5:52 PM, J. Roeleveld <joost@××××××××.org> wrote: |
| 2 |
> On Tue, February 18, 2014 10:47, Alan McKinnon wrote: |
| 3 |
>> On 18/02/2014 05:46, Mark David Dumlao wrote: |
| 4 |
>>> I used to use cherokee. Fast, light, awesome, and with a web admin. |
| 5 |
>>> The init script always failed me. /etc/init.d/cherokee stop was not a |
| 6 |
>>> guaranteed stop to all forked cherokee processes - the parent pid |
| 7 |
>>> dies, but some forked process or something, usually related to |
| 8 |
>>> rrdtool, doesn't. Or the parent does exit and erases the pid file but |
| 9 |
>>> it returns control immediately and its not yet done exiting. Something |
| 10 |
>>> like that or other. Point is, I've several times had to ps aux|grep |
| 11 |
>>> ... kill; zap; start - on production servers. |
| 12 |
>> |
| 13 |
>> |
| 14 |
>> Valid point. Other than vixie-cron (damn thing just never seems to die |
| 15 |
>> properly on any platform so restarts always fail) I don't really run |
| 16 |
>> into these issues |
| 17 |
> |
| 18 |
> Interesting, I have never had issues with restarting vixie-cron using the |
| 19 |
> supplied init-scripts. |
| 20 |
> |
| 21 |
>> What I do run into is daemons that drop privs on start up, like |
| 22 |
>> tac_plus. Unwary new sysadmins always try start/stop it as root, causing |
| 23 |
>> an unholy mess. Root the owns the log and pid files, when tac_plus drops |
| 24 |
>> privs it can't record it's state so continues to service requests but |
| 25 |
>> fails to log any of them. For an auth daemon, that's a serious issue. |
| 26 |
> |
| 27 |
> Shouldn't sysadmins use the init-scripts for that? |
| 28 |
> If done correctly, permissions should not be an issue. |
| 29 |
> |
| 30 |
> Restarting services without keeping file ownership into account will |
| 31 |
> always cause issues. Regardless of the init-system used. |
| 32 |
> |
| 33 |
|
| 34 |
That's just the thing though. As a sysadmin, how do you debug a service |
| 35 |
that isn't starting to begin with? Let's say your new to the service. You're |
| 36 |
not even sure if you got the config right the first time around. Or maybe |
| 37 |
you're adjusting a setting somewhere, and you're confused why it |
| 38 |
isn't taking effect. |
| 39 |
|
| 40 |
All the /upstream documentation/, all the /man pages/, all the /usr/share/doc |
| 41 |
stuff will tell you to start it _raw_. The init script obscures the |
| 42 |
starting options, |
| 43 |
environment variables, and sometimes even the running user from you. What are |
| 44 |
you gonna do, play a human shell script parser? Nobody's perfect, do it |
| 45 |
enough times and you're going to casually gloss over the line where |
| 46 |
--safe-mode is appended to the string depending on the phase of |
| 47 |
the moon... |
| 48 |
|
| 49 |
If you're lucky, you've never had to start an unfamiliar service, or debug |
| 50 |
someone else's unfamiliar config under time pressure... |
| 51 |
|
| 52 |
-- |
| 53 |
This email is: [ ] actionable [ ] fyi [x] social |
| 54 |
Response needed: [ ] yes [x] up to you [ ] no |
| 55 |
Time-sensitive: [ ] immediate [ ] soon [x] none |
Archives