Log in

No account? Create an account

Fri, Mar. 2nd, 2007, 01:54 am
Why oh why...

Why oh why do most daemons fork into the background by default? For example:

  gnome-screensaver [OPTION...]

Help Options:
  -?, --help               Show help options
  --help-all               Show all help options
  --help-gtk               Show GTK+ Options

Application Options:
  --version                Version of this application
  --no-daemon              Don't become a daemon
  --debug                  Enable debugging code
  --display=DISPLAY        X display to use

If I'm going to run a daemon manually, chances are that I'm trying to debug it. When you're debugging things, you want to be able to kill it quickly if need be (not to mention easily see what it's spewing out...). I certainly don't want it to fork into the background, daemonize itself, and start writing to the syslog (in the case of system-level daemons).

How much work is it for the writer of an initscript (or session manager, what have you) to add an argument to the program's arglist? Practically zero. Meanwhile I (the helpful person debugging your daemon) is doomed to waste valuable time figuring out how to get the behaviour that I need. This makes no sense!

Fri, Mar. 2nd, 2007 08:30 am (UTC)

Yeah, all programs ought to run in the foreground. That's why it's trivial to make a task backgrounded.

Another annoyance with modern GUI applications is that they report all sorts of junk to the console. Why do they assume I want to see that junk? Isn't that why there are verbosity switches?

Fri, Mar. 2nd, 2007 12:30 pm (UTC)

My favourite is all the KDE applications that fork into the background by default so I can't use control-C, but still spam my console like mad anyway.

Fri, Mar. 2nd, 2007 07:33 pm (UTC)

I think we need to send "modern" GUI application developers to UNIX re-education camp. Mandatory reading would be ESR's The Art of Unix Programming and djb's articles (Peter links to one of them below).

Fri, Mar. 2nd, 2007 12:29 pm (UTC)

Funny you should mention this, I had to turn a script into a daemon yesterday and ran across this. Good old DJB, being smart (no need to daemonize at all with daemontools!) yet insane (licensing).

Fear not, my script takes a "--daemonize" argument. I sure did miss WvDaemon though.

Fri, Mar. 2nd, 2007 07:30 pm (UTC)

I hear this WvStreams thing is free software. ;)

Sat, Mar. 3rd, 2007 08:59 am (UTC)

Funny you should mention it, I think I talked people into using UniConf today. That still doesn't do much for my poor little Perl script, although a C++/WvStreams rewrite is looking increasingly tempting.

Wed, Jul. 16th, 2008 10:01 pm (UTC)

A couple of months ago, the server at work which hosted a lot of our Free Software things was pulled off-line.

Fri, Mar. 2nd, 2007 04:47 pm (UTC)
(Anonymous): because otherwise you won't know when it's done starting

The link that cpirate sent above is nice, but it doesn't actually answer the question. The real question is: why would incredibly smart people, like the original designers of Unix, have made daemons fork automatically into the background when it's otherwise so annoying and besides, they *also* invented inittab and inetd which do the right thing?

The answer is that when you background a subprocess yourself, you don't know when it's "done starting." For example, if I'm starting syslogd, I don't actually want to move on to the next program (which might *require* syslogd's socket to be listening because it sends log messages) until syslogd is actually ready to receive connections, which is later than when it's simply been forked off. If you background the process yourself, there's no way for you to know... except polling, which is gross.

Incidentally, this is intimately related to the question that was asked recently on wvstreams-devel about wvfork()'s "strange" delays in the parent process:

As for KDE programs auto-backgrounding themselves, that's considerably more crazy, but it was also done for a good reason. The reason, as I understand it, is that to improve shared memory usage and speed (ie. data structure initialization, not .so files themselves) they actually ask the 'kdeinit' program to fork itself and load and run the library corresponding to their program. After that happens, the program *you* ran isn't actually do anything, so it quits. If kdeinit *isn't* running, the program (a bit confusingly) doesn't fork into the background because it doesn't need to. Try it and see!


Fri, Mar. 2nd, 2007 07:29 pm (UTC)
wlach: Re: because otherwise you won't know when it's done starting

Good point, but that's only an argument to make forking into the background an option (passed to the program on the command line). not for making it the default.

The KDE stuff is interesting... I guess the jury's still out on whether or not they did the most sensible thing (I can see arguments both for and against making using kdeinit the default).

Fri, Mar. 2nd, 2007 10:28 pm (UTC)
pphaneuf: Re: because otherwise you won't know when it's done starting

They could have left the original process running, forwarding the stdin/out/err and signals to/from kdeinit. I understand why kdeinit is called upon, but that's no excuse to behave so impolitely!

I don't think the kdeinit does much in the way of initializing data structures or sharing more memory, but oh boy, are there ever a lot of symbols in those C++ libraries! As they say, "relocation, relocation, relocation"...

Tue, Mar. 6th, 2007 01:14 pm (UTC)
(Anonymous): Because it makes perfect sense

Daemons are meant to run in the background -- if you are running in the FG you are doing something that is atypical. Good design handles the typical case by default and allows the atypical via command line options. You are basically asking for a bad design to cater to your laziness -- how much work is it for a developer to add an argument to the program's arglist for it not to fork when debugging it ?

Tue, Mar. 6th, 2007 04:37 pm (UTC)
wlach: Re: Because it makes perfect sense

Didn't you know that laziness is one of the three programmer virtues? :) "Good design" isn't about the rigid application of rigid rules, it's about trading off the needs of your users (and in the case of free software, your potential contributors) against the ease and simplicity of implementation. So let's take a look:

Who's going to want to fork the daemon into the background? People writing initscripts and session management applications. They will write the code to do this once, and would (I hope) look at your program's manpage before doing so. Who's going to run your daemon in the foreground? Most likely someone trying to debug your daemon when something's gone wrong (otherwise, why not let the system initialize it?). No, it's not a lot of typing and looking up, but debugging and testing is all about fast turnaround cycles.

The implementation is virtually the same for both in almost all cases.

Where does this leave us? In my opinion, the balance is that we should optimize for the person debugging it as (1) your daemon is going to be debugged many, many more times than it is going to be written into an init or session management script and
(2) fast turnaround times are much more important when a user is debugging.

I thought all of this was fairly obvious, but I guess not. Hope this explains things a bit better. By the way, I consider it rather rude to write a comment in my journal without identifying yourself.

Fri, Jul. 11th, 2008 02:31 pm (UTC)

I think you could get a few good theses from thrying to design something better than having the owner of the resource provide a setuid program to provide access.

Sat, Oct. 20th, 2007 12:04 am (UTC)

A daemon is, by definition, supposed to run in the background.

That's one of the things that makes it a daemon.