On Wed, Jun 21, 2006 at 09:36:37AM -0300, Henrique de Moraes Holschuh wrote: > 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
Well, with a different software design such ``don't kill unfortunately-named user processes'' problem can be eliminated completely. There's much better design of IPC than writing a pid to a text file, and have other processes read that file and send signals to the pid: Instead of writing their pid to a file, daemons could maintain a fifo and read (one-byte) commands from there; if there's no reader on the fifo, the daemon isn't running and nothing bad happens. Or better yet, instead of duplicating such code in each and every daemon, as already done for fork/exec, detach from terminal, cleanup filedescriptors, setsid(), write pid file, remove all that duplicated code, and have the service daemon run under a parent supervisor process which maintains such a fifo. The parent process always already knows the pid to send signals to, and knows about a service daemon terminating through SIGCHLD. Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
