I'm looking for ways to speed up the boot time on a single core embedded Linux system. Significant lag happens during start up of some custom daemons. Once they are up, they do run in the background, but the process of getting them to run takes too long.

##This takes long during startup
##In file /etc/init.d/run_custom_daemon
/opt/bin/custom_daemon -d

I've experienced a decrease in boot time if I put the starting of the daemons in the background.

##This takes much less but is it a real gain?
##In file /etc/init.d/run_custom_daemon
/opt/bin/custom_daemon -d &

From the point of view of someone just looking how long it takes to get to the login screen, this could seem like a speed up. However, I feel that this might be just a cosmetic gain which might lead to issues if the next process in the boot sequence would expect the daemon to be running at the point it is starting.

Is this a correct assumption?

  • 4
    Yes, and this is why new init systems like upstart or systemd want more details on service dependencies so they know what they can start in parallel. Feb 3, 2015 at 10:15
  • 1
    By putting it in the background directly also means that the script can't check whether starting the daemon was successful.
    – wurtel
    Feb 3, 2015 at 11:02

1 Answer 1


Usually daemons double or triple fork and the parents exit. When a daemon is started in bg, the non-interactive shell doesn't wait for the first fork to exit. And because it's got nothing to do it just exits immediately. This may speed up a bit. I don't think of any bad consequences of this if you are sure that the daemon won't fail.

To do away with a fork and consequently speed up, it might be 'exec'd like exec daemon. But 'bg' and 'exec' can't get return value of the daemon.

By the time 'init' or some agent spawned by init has figured out by some shell magic, the next init script to run and cloned itself to exec 'the next init scritp' and the exec[lv]* family of functions has found #! and run the interpreter with 'the next init script' as its arguments and the interpreter has parsed and executed 'the next init script' up to starting the next daemon with kernel grabbing cpu time intermittently..., the first daemon would have hopefully started.

The first fork of a some daemon has nothing to do except checking exit of second 'fork' syscall and exit. Other may close open 'fd's and open /dev/null on 0,1 and 2 in the first fork than postponing. Some benchmarking may reveal perfromance.

  • And because it's got nothing to do it just exits immediately I think this can cause problems even if the daemon successfully starts. What if the next init script depends on the daemon already running? Feb 3, 2015 at 18:26
  • Let me elaborate on the post. Feb 4, 2015 at 11:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .