1

Reading one of Stephen's excellent replies,

When the operating system shuts down, processes are shut down using SIGTERM and SIGKILL, but those signals don’t come from the kernel (or not directly — calling kill() with a pid of 0 or a negative pid will result in the kernel sending the signal to a number of processes). They come from a service manager terminating its services and from various last-ditch-kill-everything application-mode programs that are part of the system management mechanism: e.g. the killprocs van Smoorenburg rc script, the killprocs OpenRC script, and the systemd-shutdown program.

When the OS shuts down,

  • How does a service manager know that it should terminates its services? Is the service manager notified by receiving SIGKILL or SIGTERM or some other signal from the kernel or some process?

  • Similarly how do various last-ditch-kill-everything application-mode programs that are part of the system management mechanism know that they should send out SIGTERM and SIGKILL?

Thanks.

Community
  • 1
Tim
  • 101,790

1 Answers1

2

A service manager knows it should terminate its services because the system administrator asked it to halt or reboot the system. When the administrator runs reboot, or the user chooses the corresponding option in his/her desktop environment, the init process is told to reboot (not the kernel, at this point). The init process takes care of everything it’s been configured to do before asking the kernel to actually reboot.

The last-ditch, kill-everything phase is part of the shutdown procedure: once the shutdown procedure has asked all running services to stop, it typically waits a short while, then kills any remaining processes.

The various init systems have different implementations of all this. With sysvinit, halting or rebooting is a runlevel transition, started by asking the running init to switch to the appropriate runlevel (see the telinit manpage for details). With systemd, it’s a target, which ends up running the systemd-halt service.

Stephen Kitt
  • 434,908
  • Thanks. Does reboot notify init process to reboot, by sending some signal to init? Does init process notify a service manager to terminate its services, by execve() on the service manager with some argument, instead of sending some signal to the service manager process? – Tim Dec 18 '18 at 06:02
  • 1
    That depends on the init system being used. See the links for details. – Stephen Kitt Dec 18 '18 at 06:15
  • @Tim systemd use dbus to communicate with systemctl(or you may call it as reboot). I don't understand your statement of "execve() on some process". systemd IS BOTH the init and service manager, and it has complex logic to terminate your services, including pre-defined actions in unit files and signals. – 炸鱼薯条德里克 Dec 18 '18 at 06:18
  • "When the administrator runs reboot, or the user chooses the corresponding option in his/her desktop environment, the init process is told to reboot." How is the init process told to reboot? What if systemd? – Tim Dec 18 '18 at 14:32
  • Is reboot running in its own process? How does it notify the init process? By some signal? – Tim Dec 18 '18 at 14:38
  • @神秘德里克 Thanks. "systemd IS BOTH the init and service manager". Is it correct that sysvinit is an init system, but not a service manager? Before systemd, what was the service manager widely used? – Tim Dec 18 '18 at 17:32
  • @Tim reboot run its own process, like any other external commands you run from shell. The init is told to do some action, by IPC. The exact implementation, of course, depends on the init system you use. Before systemd era, it's sysvinit, which I don't know too much about. Sorry. – 炸鱼薯条德里克 Dec 19 '18 at 01:13
  • @神秘德里克Thanks. Systemd "has complex logic to terminate your services, including pre-defined actions in unit files and signals." Do you mean that systemd terminate services, not by sending SIGTERM or SIGKILL to the services (the quote in my post from Stephen seems to say it is by sending SIGTERM and SIGKILL), but by calling the kill or stop commands of the services? – Tim Dec 19 '18 at 03:47
  • @Tim Yes. But I believe if the service processes don't terminate with some delay, systemd will send signals to kill them anyway. For detail, please read document of service unit file. The terminate services behavior strongly depends on int init and service manager system you use. Basically, systemd is designed to terminate your services peacefully, so no trouble for the next boot. Signals is the worst way to do IPC, which usually cause trouble, but used by some good-old code – 炸鱼薯条德里克 Dec 19 '18 at 05:48
  • @Tim you’re using a quote from an answer to a question about the use of signals, that’s why it only talks about signals. In this answer, notice “once the shutdown procedure has asked all running services to stop, it typically waits a short while, then kills any remaining processes.” – Stephen Kitt Dec 19 '18 at 05:52