0
  1. Are all the daemons (services) indicated by configuration-files/scripts/links in /etc/init/, /etc/init.d/ meant to start at the boot; so can I assume those directories being like start-up directory for the processes during the boot-up?

  2. Keeping in mind multiprocessing, will stopping some or more of those from getting to start at boot actually speed-up the system boot time?

  3. Are the processes just triggered to start or is there some return code checking going on too?

2
  1. No, /etc/init.d/ and /etc/init are used to store the startup scripts of various processes used on your system. Having a script in these directory doesn't mean that they are going to start.
    For the script in /etc/init.d, there should be a link in one of the /etc/rc*.d directories to start or stop them (symbolic link) managed by the update-rc.d tool.
    Services in these directories are usually started / stopped / restarted by the sudo service <service name> <action> command. For the scripts in /etc/init, these are part of the new boot mechanism offered by upstart. The file in the /etc/init directory contains information about when and how to start and stop the service they offer.
    Services in this directory are usually started / stopped / restarted by sudo <action> <service name>.

  2. Of course, less services to start means less time to wait during boot. But take care of not disabling services needed by your system to function properly (like udev, dbus, ...)

  3. For services started from /etc/init.d, the startup script should implement in it various check to report that the service is well started or not. Usually this translate by a line saying " started" or " not started" or some other error message. This appears at the console and should also be logged into /var/log/boot.log.
    For services started by upstart (using /etc/init directory), the upstart process itself provides a way to automatically restart services that may fail, manage the dependencies between them (start service1 prior to service2 if service2 needs service1 to start / function).

  • do you imply a sequential start of the services? – precise Aug 7 '14 at 15:01
  • 1
    @rusty: for the services managed by upstart I don't know if they can be started in parallel or not. For the services started using the old way (/etc/init.d and the /etc/rc*.d directories), scripts are started one after the other using the order defined by the name of the symbolic link in /etc/rc*.d. The name is of the form SxxNAME or KxxNAME -> S to start, K to kill and xx is a number to order the sequential start of the services (lower number are started first). – Benoit Aug 8 '14 at 8:39
  • I'm still confused about which among or all of the processes /etc/rc?.d/* has more effect on the boot-up time.. Is it just those in /etc/rcS.d/ which seems the first ones to start? I read a little about the run levels and that got me to assume that those in rc0.d, rc6.d should not affect the boot nor should those with run levels 1 to 5, but again I can also see some S* scripts in run-level 0 and 6! What am I not getting here? – precise Aug 8 '14 at 11:58
  • 1
    By default, an Ubuntu system boot into runlevel 2, so the one in /etc/rc2.d will be run. Runlevel 0 is the shutdown, runlevel 6 is the reboot. S is the single-user mode (or recovery mode). Which process has more effect the boot-up time is process dependent ! You have to review all of them one by one to see which one is taken a lot of time to be started. There is no magic in there, just try and error. – Benoit Aug 8 '14 at 12:02
  • actually I've read 1 is the single user mode and S is the first one to start and takes care of the rest.. also some S* scripts in runlevels 0 and 6 confuses me! ..so I assume even there's some priority for the rc?.d/ directories in Debian perhaps, first S and then the other (default 2)?! – precise Aug 8 '14 at 12:08
0
sudo apt-get install bum

Bum is a boot up manager,it allows u to detect and manipulate the daemons and processes which start at boot up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.