Article 13 of 15
Shutting Down: SysVinit’s Other Half
An init system also shuts the system down.
Leaving a Runlevel
We know that BcalcOS normally operates in runlevel 2. Its /etc/inittab also contains entries for the other runlevels:
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
...
l6:6:wait:/etc/init.d/rc 6
Two of these are particularly important when discussing shutdown:
Runlevel 0 → halt
Runlevel 6 → reboot
So shutting down isn’t simply a matter of turning off the computer. From SysVinit’s point of view, the system is transitioning from its current operating state to another state.
Conceptually:
Normal operation
│
├────→ Runlevel 0 → Halt
│
└────→ Runlevel 6 → Reboot
The system has a defined destination and the transition to that destination is managed.
Services Have to Go Offline Too
When BcalcOS is running, many services may be active: networking, logging, scheduled tasks, device services, printing, the graphical display manager, and others.
Those services don’t necessarily want to disappear without warning. A service may have files open, data waiting to be written, network connections to close, or other cleanup to perform.
That’s why the init scripts contain both start and stop operations. /etc/init.d/cron knows how to start and stop cron. /etc/init.d/slim knows how to start and stop SLiM.
The K Entries
This brings us back to the runlevel configuration in /etc/rc2.d/. Alongside the S entries that start services, the K entries, for example, K01speech-dispatcher, tell the system to stop the associated service.
Shutdown has its own configuration too. When the system heads toward halt, the directory in charge is /etc/rc0.d/, which contains the stop links for that transition. Here’s a sample from BcalcOS:
K01slim K04rsyslog K09cryptdisks
K01speech-dispatcher K05umountnfs.sh K11umountroot
K01network-manager K07networking K12halt
K03sendsigs K08umountfs
Notice the ordering. SLiM stops first, at K01, while the system logger doesn’t stop until K04. That’s dependency information at work again, just as in startup: a service that other services rely on stops after the services that depend on it have already gone quiet. The numbers aren’t random and they aren’t simply the reverse of the startup order. They’re computed from the same kind of dependency relationships we saw in the startup order.
The final script in the sequence K12halt, after every service has been stopped and the filesystems have been unmounted, is the one that actually performs the halt.
Just as /etc/init.d/.depend.start records startup dependencies, shutdown dependencies are recorded in /etc/init.d/.depend.stop. Both are plain text.
How Services Know When to Stop
The LSB header in an init script includes a Default-Stop field:
### BEGIN INIT INFO
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
### END INIT INFO
That field determines which runlevels get stop links for the service. SLiM’s Default-Stop: 0 1 6 means SLiM is configured to be stopped whenever the system enters runlevel 0 (halt), runlevel 1 (single-user), or runlevel 6 (reboot).
This is how the system knows which services participate in shutdown: the same header information that helped arrange startup also determines the stop-side configuration.
Startup and Shutdown Are Related
Earlier in the series, we reduced BcalcOS startup to:
Linux kernel
↓
SysVinit
↓
system initialization
↓
runlevel 2
↓
services
↓
graphical login
Shutdown follows the same general model in reverse:
graphical session
↓
services
↓
leave runlevel 2
↓
stop services
↓
halt or reboot
It isn’t a perfect mirror image. Just as we saw with the K entries, stopping has its own computed order rather than simply running the startup sequence backwards but the basic idea is the same.
Why an Orderly Shutdown Matters
If a computer is simply powered off while software is still working, the operating system has no opportunity to finish what it’s doing.
That can mean:
- data that hasn’t been written yet may be lost
- filesystems may need additional recovery on the next boot
- network connections disappear without being closed normally
- services cannot perform their normal cleanup
While the system is running, it may be writing files to disk, updating logs, finishing background operations, or managing removable devices. A controlled shutdown gives all of those operations a chance to finish.
Near the end of the shutdown sequence, the system finishes writing any pending data to disk and unmounts the filesystems—the entries K08umountfs and K11umountroot in our listing above are exactly that work, in order. Only after that does the final halt script run. A system that is simply powered off skips all of this, and the filesystem must sort out the consequences on the next boot.
The physical power button can still be useful when a computer is completely unresponsive, but it should not be the normal way to shut down a functioning system.
Shutting Down or Rebooting
Here are a few associated commands for a SysVinit-based system.
To shut down: sudo shutdown -h now
To reboot: sudo shutdown -r now
Or sudo halt and sudo reboot which are convenient shorthand for the same results. sudo init 0 / sudo init 6 which ask init directly for a runlevel transition.
All of these ultimately request the same thing: a managed transition of the operating state. The shutdown command can also schedule a shutdown for a later time and warn logged-in users beforehand.
Behind the scenes, the system is transitioning through a managed process:
Request shutdown
↓
Stop services
↓
Close user sessions
↓
Finish system operations
↓
Halt
A reboot follows essentially the same process, except that the system starts again afterward.
The familiar Ctrl+Alt+Del key combination is mapped through this system.
BcalcOS’s /etc/inittab includes this entry: ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
When Ctrl+Alt+Del is pressed, init runs the shutdown command, a managed reboot, not a hardware reset.
When a Service Won’t Stop
Occasionally, a service may hang during shutdown instead of stopping cleanly. Perhaps because it’s waiting on a network resource or stuck on a problem in its own program.
When a service is asked to stop, it’s first asked to clean up and exit. If it never responds, the system eventually forces the issue. That waiting period is often the reason a shutdown seems to take longer than usual.
The logs under /var/log/ usually record which service caused the problem and you can test the suspect in isolation with its stop command:
sudo /etc/init.d/service-name stop
If that hangs too, the problem is with the service itself, not with the shutdown sequence.
Key Takeaway
SysVinit manages transitions between operating states. Starting the system is one such transition. Stopping or rebooting it is another.
- Runlevel 0 is halt; runlevel 6 is reboot.
/etc/rc0.d/holds the stop links for the halt transition, with numbers computed from shutdown dependencies so that dependents stop before the services they rely on.- The
Default-Stopfield in each init script’s LSB header determines which runlevels stop that service. - Init scripts contain stop operations so services can close files, flush data, and clean up.