HomeCode archaeology
When things become relevant again
One thing I have been doing over the past few weeks is: finally, finally, taking the hard drive out of my last desktop computer—last used about 8 years ago at a guess—and actually copying all the documents off it. It also had stuff preserved from pretty much every desktop machine I’d had before that, so there was a whole treasure-chest of photographs I hadn’t seen in years, things I’d written, and various incomplete coding projects.
Some of the photos will no doubt get posted on here over the coming weeks, but this post isn’t about those. Because, by pure coincidence, I was browsing my Twitter feed this morning and saw this tweet from @ireneista:
we were trying to help a friend get up to speed on how to make a Unix process into a daemon, which is something we found plenty of guides on in the 90s but it’s largely forgotten knowledge
Hang on a minute, I think. Haven’t I just been pulling old incomplete coding projects off my old hard disk and saving them into Github repositories instead? And don’t some of those have exactly that code in? A daemon, on Unix, is roughly the equivalent of a “Service” on Windows. It’s a program that runs all the time in the background on a computer, doing important work.* Many servers don’t even run anything else to speak of. On both Unix and Windows systems, there are special steps you have to take to properly “detach” your code and let it run in the background as part of the system, and if you don’t do all those steps properly you will either produce something that is liable to break and stop running that it’s not supposed to, or write something that fills up your system’s process table with so-called “zombie” entries for processes that have stopped running but still need some bookkeeping information kept about them.
Is this forgotten knowledge? Well, it’s certainly not something I would be able to do, off the top of my head, without a lot of recourse to documentation. For a start all the past projects I’m talking about were written in C, for Linux systems, and I haven’t touched the language nor the operating system much for a number of years now.
None of the projects I’m talking about ever approached completion or were properly tested, so there’s not that much point releasing their full source code to the world. However, clearly, the information about how to set up a daemon has disappeared out of circulation a bit. Moreover, that code was generally stuff that I pulled wholesale from Usenet FAQs myself, tidying it up and adding extra logging as I needed, so compared to the rest of the projects, it’s probably much more reliable. The tweet thread above links to some CIA documentation released by Wikileaks which is nice and explanatory, but doesn’t actually include some of the things I always did when starting up a daemon. You could, of course, argue they’re not always needed. So, here is some daemonisation code I have cobbled together by taking an average across the code I was writing about twenty-ish years ago and adding a bit of explanation. Hopefully this will be useful to somebody.
Bear in mind this isn’t real code: it depends on functions and variables that you can assume we’ve declared in headers, or in the parts of the code that have been omitted. As the old saying goes, I accept no responsibility if this code causes loss, damage, or demons flying out of your nose.**
/* You can look up yourself which headers you'll need to include */
int main(int argc, char **argv)
{
/*
* First you'll want to read config and process command line args,
* because it might be nice to include an argument to say "dont'
* run as a daemon!" if you fancy that.
*
* This code is also written to use GNU intltools, and the setup for that
* goes here too.
*/
/* Assume the daemonise variable was set by processing the config */
if (daemonise)
{
/* First we fork to a new process and exit the original process */
switch (fork ())
{
case -1:
syslog (LOG_ERR, _("Forking hell, aborting."));
exit (EXIT_FAILURE);
default:
exit (0);
case 0:
break;
}
/* Then we call setsid() to become a process group leader, making sure we are detached
* from any terminals */
if (setsid () == -1)
{
syslog (LOG_ERR, _("setsid() failed, aborting."));
exit (EXIT_FAILURE);
}
/* Then we fork again */
switch (fork ())
{
case -1:
syslog (LOG_ERR, _("Forking hell x2, aborting."));
exit (EXIT_FAILURE);
default:
exit (0);
case 0:
break;
}
/* Next, a bit of cleanup. Change our CWD to / so we don't block any umounts, and
* redirect our standard streams to taste */
umask (0022);
if (chdir ("/"))
syslog (LOG_WARNING, _("Cannot chdir to root directory"));
freopen ("/dev/null", "w", stdout);
freopen ("/dev/null", "r", stdin);
freopen ("/dev/console", "w", stderr); /* This one in particular might not be what you want */
/*
* Listen to some signals. The second parameters are function pointers which
* you'll have to imagine are defined elsewhere. Reloading config on SIGHUP
* is a common daemon behaviour you might want. I can't remember why I thought
* it important to ignore SIGPIPE
*/
signal (SIGPIPE, SIG_IGN);
signal (SIGHUP, warm_restart);
signal (SIGQUIT, graceful_shutdown);
signal (SIGTERM, graceful_shutdown);
/* And now we're done! Let's go and run the rest of our code */
run_the_daemon ();
}
}The above probably includes some horrible mistake somewhere along the way, but hopefully it’s not too inaccurate, and hopefully would work in the real world. If you try it—or have opinions about it—please do get in touch and let me know.
* NB: this is a simplification for the benefit of the non-technical. Yes, I know I’m generalising and lots of daemons and services don’t run all the time. Please don’t write in with examples.
** “demons flying out of your nose” was a running joke in the comp.lang.c Usenet group, for something it would be considered entirely legitimate for a C compiler to do if you wrote code that was described in the C language standard as having “undefined behaviour”.
Newer posts »