![]() Paste buffer, then writes the paste buffer to a file, then clears the paste buffer. It pulls the $PID out of the environment of screen's child process and puts it in the $PID' 'writebuf /tmp/foobar.txt' 'register. The permissions and SELinux fiddly bits but.Įval 'register. The very first commands will drop the PID into a named file. In that case simply using a startup file with this line run as one of Always Innovating Touch Book, Part 1 - First Impressionsīelieve it or not years later this is still a very useful post, Thank you.Īn alternative, sleazy way to get the PID into a file assumes you are allowed to hijack the.Sometimes you just have to let it go - your old GNU Emacs config, that is.Migration Finally Complete, Part 2 (Web server).I wonder if RHEL/CentOS have the start-stop-daemon in repos, last time I checked they didn't, and it'd be very useful if they did (I'd avoid doing ridiculous stuff inside my init.d scripts for them just to get JBoss up and going). Of course, it can be useful to have some more complex checks for status, but for basic usage this is quite enough. I can switch over to exploiting start-stop-daemon's functionality in this area instead. 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).Īll in all, I've really grown to like start-stop-daemon and what it can do (the LSB's start_daemon function has much less options, and what's particularly annoying about it is the complete lack of options for specifying the UID/GID and such.Īnd the best 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. 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). Now, since start-stop-daemon doesn't know about that newly created process, it uses the first process' PID, which is wrong, of course.Īfter 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. 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. 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. ![]() With start-stop-daemon you can specify UID/GID of the user who should execute the process etc. One of the nice things it supports is reading/writing of PID file. ![]() It can be used for both starting and stopping processes (daemons) without killing wrong processes (with similar name) by mistake. As for start-stop-daemon, it is an essential piece of software used by both Debian and Gentoo during the boot process. 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. 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).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |