I've been playing a bit with GNU Screen and start-stop-daemon today, trying to rewrite the irssi init.d script (which allows me to run irssi within GNU Screen upon boot). <!--break--> GNU Screen is a very hand tool allowing you to keep a process running even when you log out, or in this case, even while you haven't logged in yet. As for start-stop-daemon, it is an essential piece of software used by both Debian and Gentoo during the boot process. It can be used for both starting and stopping processes (daemons) without killing wrong processes (with similar name) by mistake. One of the nice things it supports is reading/writing of PID file. But its usefulness doesn't end there. With start-stop-daemon you can specify UID/GID of the user who should execute the process etc.
The problem I've ran into, though, is that when using screen with arguments '-d -m' (which detaches the screen into background right away) in conjunction with start-stop-daemon's --make-pidfile, the PID file keeps getting a wrong PID written to it. To be more precise, it seems (I haven't looked into GNU Screen code to verify this, but I think that's what happens) that when you start screen with above arguments, it creates another process, and that's the main process to which you can attach later on, while the original process is killed. Now, since start-stop-daemon doesn't know about that newly created process, it uses the first process' PID, which is wrong, of course.
After playing around with this thing I came to conclusion that it'd be best to use GNU Screen with '-D -m' arguments and start-stop-daemon's --background flag. That, or add a new argument to GNU Screen allowing it to write its PID to a specified file (which might actually be rather nice if I have time/will to work on it). Of course, several other things are going around my head now as well, like tracking if the irssi process itself is alive and well instead of GNU Screen process which ran it (since it's not impossible for irssi to die within the GNU Screen, but the GNU Screen might keep going - even with '-D -m' - if the user created some other session by mistake, causing, for example, /etc/init.d/irssid status to return 0 instead of 1/3).
All in all, I've really grown to like start-stop-daemon and what it can do (the LSB's start_daemon function has <i>much</i> less options, and what's particularly annoying about it is the complete lack of options for specifying the UID/GID and such.
And the <i>best</i> thing about this adventure is that now I can dump the 'checkRunning' function I made for checking if some process is still running or not. I can switch over to exploiting start-stop-daemon's functionality in this area instead. Of course, it can be useful to have some more complex checks for status, but for basic usage this is quite enough.
P.S. I wonder if RHEL/CentOS have the start-stop-daemon in repos, last time I checked they didn't, and it'd be <i>very</i> useful if they did (I'd avoid doing ridiculous stuff inside my init.d scripts for them just to get JBoss up and going).
on #
Immensely helpful. Thank you!
on #
Really helpful!
skids on #
Believe it or not years later this is still a very useful post, Thank you.
An alternative, sleazy way to get the PID into a file assumes you are allowed to hijack the
normal starup file. In that case simply using a startup file with this line run as one of
the very first commands will drop the PID into a named file. Of course, then there's all
the permissions and SELinux fiddly bits but...
eval 'register . $PID' 'writebuf /tmp/foobar.txt' 'register . ""'
It pulls the $PID out of the environment of screen's child process and puts it in the
paste buffer, then writes the paste buffer to a file, then clears the paste buffer. You
would then be able to source the original startup file, though implementing the $SCREENRC
defaulting logic is left as an exercise.
Unfortunately you cannot use -d -m -X to provide a one-shot commandline as -X expects to
work on a previously started session. Also note that at the point it looks at $PID, $STY does
not yet contain the PID prefix, so you can't just use that.
Branko Majic on #
Thanks, good to know it's not just bots visiting and posting on these pages nowadays :)