Gentoo Archives: gentoo-dev

From: Eric Sammer <eric@××××××××××××.com>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] Racing in init scripts
Date: Wed, 15 Oct 2003 08:42:30
Message-Id: 3F8D0875.1090408@ineoconcepts.com
In Reply to: Re: [gentoo-dev] Racing in init scripts by Paul de Vrieze
1 Paul de Vrieze wrote:
2 > In general that status part of the init scripts deserves some fixing too. The
3 > problem is that this status checks whether the service is supposed to be
4 > running, not whether it is actually running.
5
6 That combined with the race aspect creates the need for 'zap' -
7 something that should arguably never be needed. It would be nice to see
8 that go away (the need for it, I mean).
9
10 > If we were to implement a status
11 > function we could use that for the restart too (only start when the status
12 > returns that it is actually not running anymore, or after a predetermined
13 > time has passed, say 10 seconds)
14
15 That would be nice. Of course, this is very application-centric due to
16 the numerous methods of defining "running" - a pid file, a process being
17 up, etc.
18
19 I suppose it if were to be abstracted by a function call where the app
20 specific work can be done (as I believe it to be now), it would be
21 feasible. I think it's a matter of it bothering enough people before it
22 gets looked at. The problem exists more so in potentia (unless people
23 are restarting things automagically) than in normal day to day operation.
24
25 I did find one instance where this is problematic: When using logrotate
26 to handle log files, some apps need to be restarted to create and start
27 logging again. In this case, one would be shooting themselves in the
28 foot by using the init scripts in their current incarnation - your
29 services wouldn't come back up. This would be A Very Bad Thing(tm).
30
31 --
32 Eric Sammer
33 eric@××××××××××××.com
34 http://www.ineoconcepts.com
35
36
37 --
38 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] Racing in init scripts Corvus Corax <corvus-ml@×××××××××××.com>