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?

  • Each init script is run in its own shell. – bahamat Jan 25 '14 at 8:41

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.

    ss #1

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.

| improve this answer | |
  • 1
    That there is much boilerplate redone with shell scripts is exactly one of the big reasons why Linux distributions are getting rid of this whole mess. – vonbrand Jan 24 '14 at 17:34
  • 1
    All true; still, spawning new shells has a cost, which is why (IIRC) Debian uses the slimmed-down dash for startup purposes instead of a more heavyweight bash, for example. – Ulrich Schwarz Jan 24 '14 at 18:26
  • Ok thanks, that answers the question as to how things are, still one could wish for something a bit less laborious, like making the log functions somehow universally available. Still, I can see that the current method is at least robust. We'll see what future init methods bring to this. Thanks again. – Ray Andrews Jan 24 '14 at 22:19

As far as I saw, only the scripts in /etc/init.d/ and /etc/network sourcing the files in /lib/lsb/init-functions, they are not sourced again and again, only once for each script and each script needs to source it once because each script can be started separately.

[Edit #1]

Important to know is, when the file was read once, it will by cached by the system. So it doesn't take any time if the file has to be read again. Plus, the files in /etc/lsb/init-functions contain only definition of subroutines, they wont be executed when sourced.

[Edit #2]

I checked this once again and wanted to know how long does it take to source some script. So I switched to init 1 to be sure that no other process disturbs the measurement. Here are the results:

find /lib/lsb -type f -ls
9951842    4 -rw-r--r--   1 root     root         1088 Jun  5  2013 /lib/lsb/init-functions.d/20-left-info-blocks  
9952149    4 -rw-r--r--   1 root     root         2408 Dec 31 19:24 /lib/lsb/init-functions.d/40-systemd  
9951841   12 -rw-r--r--   1 root     root        11506 May 15  2013 /lib/lsb/init-functions 

So these are 3 scripts and about 15k of storage

The test is a simple bash loop

time bash -c 'for i in {1..10000}; do source /lib/lsb/init-functions; done'
real   0m27.342s
user   0m17.756s
sys    0m1.328s

This means 27.342/10000/3 = 0.0009 seconds average to source one script on a 3.4Ghz Core 2 Duo.

| improve this answer | |
  • Sure, just once per script, but even that seems wasteful, but if each process has it's own shell, then I guess it can't be helped. – Ray Andrews Jan 24 '14 at 22:15
  • Also every ELF executable loads it's libraries ondemand at runtime, the text segment of the libraries is hovewer mapped efficiently once. Protected mode was till the invention of Intel i386 a desired feature. So you're right in case that it is wasteful. Anyways executing a shell script is also wasteful because it is too slow compared to an executable. Anyhow it is very powerfull and it has become a habit. Do you have alternatives? – user55518 Jan 24 '14 at 22:31
  • No alternative here! I'm just trying to understand things. – Ray Andrews Jan 25 '14 at 2:07
  • Ha! Thanks for the speed tests, that is very informative. – Ray Andrews Jan 25 '14 at 15:41

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.