1 |
On 18/02/2014 11:52, J. Roeleveld 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 |
It's a little more complex than just that. It's an auth service and user |
31 |
are frequently added, removed and modified. The daemon does syntax |
32 |
checking on it's config file at startup or after being HUP'ed but that |
33 |
only finds static errors. It catches things like adding people to a grop |
34 |
instead of to a group, but misses dynamic mistakes like adding users to |
35 |
groups that don't exist. |
36 |
|
37 |
It's exactly analogous to compile-time vs runtime errors, compilers |
38 |
can't catch the latter. |
39 |
|
40 |
Despite this all being run out of cron with wrapper scripts to check |
41 |
validity, automated additions and safety checks between all three |
42 |
daemons, plus being fully documented on the internal wiki and in bold |
43 |
blinking red caps in the login motd, people still find ways to do stuff |
44 |
things in an attempt to fix it. |
45 |
|
46 |
The daemon also tries to log these errors, by writing to a log file it |
47 |
has no write permissions on. |
48 |
|
49 |
There is nothing I can do about the quality of sysadmins, I have no |
50 |
input into the HR process and damagement think cheaper is always better, |
51 |
including skills. What I can do, is find ways to make the software more |
52 |
resistant to errors than it already is. |
53 |
|
54 |
|
55 |
|
56 |
> |
57 |
> Restarting services without keeping file ownership into account will |
58 |
> always cause issues. Regardless of the init-system used. |
59 |
> |
60 |
> And tac_plus not checking if it is allowed to write to the log during the |
61 |
> initialization phase should be considered a bug. |
62 |
> |
63 |
> -- |
64 |
> Joost |
65 |
> |
66 |
> |
67 |
> |
68 |
> |
69 |
|
70 |
|
71 |
-- |
72 |
Alan McKinnon |
73 |
alan.mckinnon@×××××.com |