Debian – Displaying all sysvinit init scripts

Lots of questions...

The basic answer to your question is yes each script is run in its own shell, or rather each process that gets exec'd contains a copy of the base environment + these variables that get included by this sourcing + any additional environment variables that are included when the service starts up.

Moving these includes, like vars.sh, to the runlevel level would be a bad idea, because then every shell would have them in that runlevel. Much of the plumbing that these scripts are creating is ultra-specific to the services that are running within the resulting shell that is the by-product of these files being sourced.

Also remember that much is buffered and cached, blocks read from the disk, for example, so you aren't necessarily reaching out to the disk every time for subsequent re-reads of these files. This is part of what's going on when you look at your system and see that it's consuming a lot of RAM.

$ free -m
             total       used       free     shared    buffers     cached
Mem:          7782       7086        696          0        218        883
-/+ buffers/cache:       5984       1797
Swap:         7823       1550       6273

The -/+ buffers/cache line is the caching of these types of blocks, related to disk I/O.

Future directions

Much of the init's derive from System V (see the Wikipedia article on init for the full history). By today's standards it is antiquated, but it has served well for roughly 20 years. But there are definitely areas where it's deficient.

So to try and address these, 2 newcomers, Systemd & Upstart have been developed, and are starting to be adopted by various Linux distributions.

Upstart's adoption has been a little bit of a roller coaster. It's developed by Canonical so it's been in Ubuntu for quite some time, and was part of Fedora as well as RHEL, CentOS, and openSUSE for a time, before they switched to systemd. It's actually still in RHEL & CentOS to a degree.

Both these systems make marked improvements over SysV init, especially in the area of being able to start services in parallel. One of init's major deficiencies. But with these systems, gone is the simplicity of opening up a couple of scripts in vim and tweaking your start up routines. These are both full blown technologies that require time to grok and fully understand.

There's some files in /etc/init.d/ directory:

$ ls -al /etc/init.d/ | grep -i depend
-rw-r--r--   1 root root  2739 Feb 17 05:20 .depend.boot
-rw-r--r--   1 root root  2221 Feb 17 05:20 .depend.start
-rw-r--r--   1 root root  1855 Feb 17 05:20 .depend.stop

Whenever you run update-rc.d the files will change. .depend.boot file is for S level, .depend.start is for 2 3 4 5 levels and .depend.stop for 0 1 6.

In my case, I have the following order in .depend.start:

TARGETS = killprocs motd nvidia-kernel nfs-common rsyslog privoxy virtualbox
linuxlogo acpi-fakekey binfmt-support fancontrol openvpn hddtemp cgconfig 
dropbox-container dbus dnscrypt-proxy pulseaudio atd cryptmount exim4 
qbittorrent-nox ddclient acpi-support smartmontools ssh ntp loadcpufreq acpid 
cron rsync cgrulesengd cpufrequtils bootlogs bootchart-done single rmnologin 
rc.local stop-bootlogd

You can also see why the order presents in the way you see above. Each next line looks like this:

cgrulesengd: rsyslog cgconfig

which means that cgrulesengd needs rsyslog cgconfig to be started prior.