Studying the init scripts, I'm puzzled as to why some subsidiary functions need to be re-sourced again and again. Specifically the logging functions found in /lib/lsb/init-functions. Every script that wants log messages needs to re-source that, why isn't it possible to do it once and that's that? It's as if each new init script is run in it's own shell. If that's the case, why do it like that? The same issue shows up with 'vars.sh' which needs to be re-sourced all the time. Is this necessary? Suppose 'init-functions' and 'vars.sh' were added to the list of scripts to run in the appropriate runlevels?
Why do some scripts need constant re-sourcing during debian init?
debian;sysvinit
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     cachedMem:          7782       7086        696          0        218        883-/+ buffers/cache:       5984       1797Swap:         7823       1550       6273The -/+ buffers/cache line is the caching of these types of blocks, related to disk I/O.Future directionsMuch 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.