Running init script which starts a daemon in background for reducing boot time?

Question

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?

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.