On Wed, 21 Jun 2006, Gerrit Pape wrote: > On Mon, Jun 05, 2006 at 03:36:30PM +0300, Lars Wirzenius wrote: > > The policy manual says (9.3.2 Writing the scripts): > > > > The init.d scripts should ensure that they will behave sensibly > > if invoked with start when the service is already running, or > > with stop when it isn't, and that they don't kill > > unfortunately-named user processes. > > > > Would it be acceptable to change this to say "must ensure"? > > You might call this nitpicking, but with the current Debian init scripts > using start-stop-daemon, this isn't really achievable. See the > start-stop-daemon(8) man page:
You should use start-stop-daemon with both --name AND --pidfile together (never use --exec unless you REALLY know you will always stop the daemon before it changes on disk) in an initscript. That changes start-stop-daemon into a homing killall. > And relying on a pidfile also doesn't guarantee that ``they don't kill > unfortunately-named user processes'', but actually can cause exactly > that, AFAICT. Nothing is 100% foolproof, of course. --exec is damn good at homing exactly on what you want, but you'd need to know the inode of the already unlinked executable if it is restarted after being upgraded. Hints are welcome, so far we got far more breakage from --exec than any benefits. A pidfile + process name check is actually quite good enough in practice, IME. I have never seen it misfire in my life other than in fabricated scenarios. Of course, bird-brain interpretors like python in which it is hell to change the process name and on top of it insist on running all scripts/programs with the interpretor name sort of widen the error window a lot more than necessary. Hints on how to fix that are very welcome, I have at least one package which would benefit from this. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
