Why programs run at boot/shutdown are written in
If a compiled language (or a faster interpreted language, like Python) was used, then its running time would be shorter.
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
It is largely historic, partly a matter of control from a system administration aspect, partly a portability issue, partly a debugging issue.
"Back in the day", there was no autoconf, dpkg, rpm. You downloaded the software, sometimes from UUCP, compiled the product and determined - with your own conventions - where to install the product. Hooking the product up to the boot/shutdown system was thought to be a duty of the system administrator. The sysadmin would write the
rc script and place it in the appropriate place for that system (
/etc/inetd.conf). With fewer of the non-linux systems in the forefront, the advent of
dpkg makes some of these local choices less important.
Systems administrators also like to have some measure of control over their systems, and the easiest write, debug and modify later are shell scripts, not C programs.
As I alluded to earlier, different UNIX OSs had different ways to boot. Writing a short shell script for your own system was much easier than the developer writing for every possible flavor of UNIX that was coming up (again, this was before even autoconf): SysV, Ultrix, Irix, HP-UX, SunOS, Solaris, NextStep, NonStop, etc. For the most part, they fell into two or three mechanisms, but each had their own twist.
Boot systems can get complicated easily. It's good to have a shell script where you can print debugging information, change the flow, handle interactions that the program authors didn't anticipate. If this was a compiled program, it would make finding such errors much more difficult.
Modern systems have newer mechanisms, but most will still call shell scripts, largely for the reasons above.
Most of the boot process is IO-bound: waiting for files to be loaded from the disk, or waiting for devices to be initialized. There wouldn't be that much to gain from using a compiled language.
Using ash instead of bash does speed up the boot process somewhat. Ash is designed to be faster and smaller than bash, which it achieves by having fewer features (POSIX and not much more). Crucially, ash starts up faster, which gives a measurable advantage because the boot process is split between many scripts. Using more Python would be likely to make the boot process slower, because a Python interpreter is bigger and takes more time starting up for each process.
Unix systems typically have one or more script per subsystem or daemon that needs to be initialized. These scripts are often tweaked by system administrators. The work is split between many small programs that come from different sources (one per subsystem). For many small, simple programs, a shell is pretty fast; there wouldn't be much to be gained by using a compiled language, but there would be a huge cost in flexibility.
Modifying a bash script is easier than locating sources for executables.
The startup scripts more often than not, are distribution specific, so eas of modification is important.
If you think that bash scripts are slow you may want to look at dash and writing POSIX compatible sh scripts that run on dash.