How does Linux operating system shut down? [on hold]











up vote
-3
down vote

favorite












Gilles wrote an excellent reply about how Linux kernel shuts down at https://unix.stackexchange.com/a/122667/674



I was wondering how Linux OS shuts down (in cases of both systemvinit and systemd)? I am expecting something similar to the boot sequence of Linux OS.
I am particularly wondering how the processes notify each other, by some signal like SIGTERM and SIGKILL, or some other interprocess communication way?



Thanks.



Related:



What is the difference between "when the operating system shuts down" and "when the kernel shuts down"?



When the operating system shuts down, how does a service manager know that it should sends SIGTERM and SIGKILL to its services?










share|improve this question















put on hold as too broad by Scott, Mr Shunz, RalfFriedl, DarkHeart, Stephen Harris 1 hour ago


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.















  • Maybe at a high level with only critical parts?
    – Tim
    yesterday










  • Don't be afraid. Since you mentioned it, I would refrain myself from doing so.
    – Tim
    yesterday















up vote
-3
down vote

favorite












Gilles wrote an excellent reply about how Linux kernel shuts down at https://unix.stackexchange.com/a/122667/674



I was wondering how Linux OS shuts down (in cases of both systemvinit and systemd)? I am expecting something similar to the boot sequence of Linux OS.
I am particularly wondering how the processes notify each other, by some signal like SIGTERM and SIGKILL, or some other interprocess communication way?



Thanks.



Related:



What is the difference between "when the operating system shuts down" and "when the kernel shuts down"?



When the operating system shuts down, how does a service manager know that it should sends SIGTERM and SIGKILL to its services?










share|improve this question















put on hold as too broad by Scott, Mr Shunz, RalfFriedl, DarkHeart, Stephen Harris 1 hour ago


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.















  • Maybe at a high level with only critical parts?
    – Tim
    yesterday










  • Don't be afraid. Since you mentioned it, I would refrain myself from doing so.
    – Tim
    yesterday













up vote
-3
down vote

favorite









up vote
-3
down vote

favorite











Gilles wrote an excellent reply about how Linux kernel shuts down at https://unix.stackexchange.com/a/122667/674



I was wondering how Linux OS shuts down (in cases of both systemvinit and systemd)? I am expecting something similar to the boot sequence of Linux OS.
I am particularly wondering how the processes notify each other, by some signal like SIGTERM and SIGKILL, or some other interprocess communication way?



Thanks.



Related:



What is the difference between "when the operating system shuts down" and "when the kernel shuts down"?



When the operating system shuts down, how does a service manager know that it should sends SIGTERM and SIGKILL to its services?










share|improve this question















Gilles wrote an excellent reply about how Linux kernel shuts down at https://unix.stackexchange.com/a/122667/674



I was wondering how Linux OS shuts down (in cases of both systemvinit and systemd)? I am expecting something similar to the boot sequence of Linux OS.
I am particularly wondering how the processes notify each other, by some signal like SIGTERM and SIGKILL, or some other interprocess communication way?



Thanks.



Related:



What is the difference between "when the operating system shuts down" and "when the kernel shuts down"?



When the operating system shuts down, how does a service manager know that it should sends SIGTERM and SIGKILL to its services?







linux systemd shutdown init






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 9 hours ago









Jeff Schaller

38.1k1053124




38.1k1053124










asked yesterday









Tim

25.5k74245449




25.5k74245449




put on hold as too broad by Scott, Mr Shunz, RalfFriedl, DarkHeart, Stephen Harris 1 hour ago


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.






put on hold as too broad by Scott, Mr Shunz, RalfFriedl, DarkHeart, Stephen Harris 1 hour ago


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.














  • Maybe at a high level with only critical parts?
    – Tim
    yesterday










  • Don't be afraid. Since you mentioned it, I would refrain myself from doing so.
    – Tim
    yesterday


















  • Maybe at a high level with only critical parts?
    – Tim
    yesterday










  • Don't be afraid. Since you mentioned it, I would refrain myself from doing so.
    – Tim
    yesterday
















Maybe at a high level with only critical parts?
– Tim
yesterday




Maybe at a high level with only critical parts?
– Tim
yesterday












Don't be afraid. Since you mentioned it, I would refrain myself from doing so.
– Tim
yesterday




Don't be afraid. Since you mentioned it, I would refrain myself from doing so.
– Tim
yesterday










1 Answer
1






active

oldest

votes

















up vote
3
down vote



accepted










With both sysvinit and systemd, shutting the operating system down starts by notifying the init process (the process with pid 1) that the system should shut down (or reboot, or power off).



sysvinit does this by using the /run/initctl FIFO to communicate with init, asking it to switch to the corresponding runlevel. See the init manpage for a brief overview.



systemd supports a variety of ways to do this. Various signals can be used to request a shutdown, reboot, etc., in various flavours; it’s also possible to request this over d-bus (the busctl manpage explains how to explore that).



Once pid 1 has been asked to shut down, it follows its configuration and specification and goes through all the appropriate steps for it. This typically includes notifying all users that a shutdown is in progress, shutting down all the running services (in a managed way with systemd; using shutdown scripts in various forms with sysvinit), syncing the mounted file systems, possibly unmounting them, killing all remaining processes (with the usual TERM then KILL sequence), and finally calling the kernel’s reboot system call with the appropriate parameters.



This describes the general sequence. There are many more twists to all this, including access control (with Polkit), various available hooks, kexec, sudden power-off handling, CtrlAltDel handling... The systemd documentation covers many of these details.






share|improve this answer























  • Thanks. In manpages.debian.org/stretch/sysvinit-core/…, init also reacts to some signals. Does that mean we can communicate with init by sending some signals instead of using FIFO, asking it to switch to the corresponding runlevel?
    – Tim
    23 hours ago










  • /run/initctl is FIFO not socket. Let me know if I am wrong.
    – Tim
    22 hours ago












  • You can use certain signals to communicate with sysvinit’s init, but none of them are relevant here. You can’t use them to request an arbitrary runlevel change.
    – Stephen Kitt
    20 hours ago


















1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
3
down vote



accepted










With both sysvinit and systemd, shutting the operating system down starts by notifying the init process (the process with pid 1) that the system should shut down (or reboot, or power off).



sysvinit does this by using the /run/initctl FIFO to communicate with init, asking it to switch to the corresponding runlevel. See the init manpage for a brief overview.



systemd supports a variety of ways to do this. Various signals can be used to request a shutdown, reboot, etc., in various flavours; it’s also possible to request this over d-bus (the busctl manpage explains how to explore that).



Once pid 1 has been asked to shut down, it follows its configuration and specification and goes through all the appropriate steps for it. This typically includes notifying all users that a shutdown is in progress, shutting down all the running services (in a managed way with systemd; using shutdown scripts in various forms with sysvinit), syncing the mounted file systems, possibly unmounting them, killing all remaining processes (with the usual TERM then KILL sequence), and finally calling the kernel’s reboot system call with the appropriate parameters.



This describes the general sequence. There are many more twists to all this, including access control (with Polkit), various available hooks, kexec, sudden power-off handling, CtrlAltDel handling... The systemd documentation covers many of these details.






share|improve this answer























  • Thanks. In manpages.debian.org/stretch/sysvinit-core/…, init also reacts to some signals. Does that mean we can communicate with init by sending some signals instead of using FIFO, asking it to switch to the corresponding runlevel?
    – Tim
    23 hours ago










  • /run/initctl is FIFO not socket. Let me know if I am wrong.
    – Tim
    22 hours ago












  • You can use certain signals to communicate with sysvinit’s init, but none of them are relevant here. You can’t use them to request an arbitrary runlevel change.
    – Stephen Kitt
    20 hours ago















up vote
3
down vote



accepted










With both sysvinit and systemd, shutting the operating system down starts by notifying the init process (the process with pid 1) that the system should shut down (or reboot, or power off).



sysvinit does this by using the /run/initctl FIFO to communicate with init, asking it to switch to the corresponding runlevel. See the init manpage for a brief overview.



systemd supports a variety of ways to do this. Various signals can be used to request a shutdown, reboot, etc., in various flavours; it’s also possible to request this over d-bus (the busctl manpage explains how to explore that).



Once pid 1 has been asked to shut down, it follows its configuration and specification and goes through all the appropriate steps for it. This typically includes notifying all users that a shutdown is in progress, shutting down all the running services (in a managed way with systemd; using shutdown scripts in various forms with sysvinit), syncing the mounted file systems, possibly unmounting them, killing all remaining processes (with the usual TERM then KILL sequence), and finally calling the kernel’s reboot system call with the appropriate parameters.



This describes the general sequence. There are many more twists to all this, including access control (with Polkit), various available hooks, kexec, sudden power-off handling, CtrlAltDel handling... The systemd documentation covers many of these details.






share|improve this answer























  • Thanks. In manpages.debian.org/stretch/sysvinit-core/…, init also reacts to some signals. Does that mean we can communicate with init by sending some signals instead of using FIFO, asking it to switch to the corresponding runlevel?
    – Tim
    23 hours ago










  • /run/initctl is FIFO not socket. Let me know if I am wrong.
    – Tim
    22 hours ago












  • You can use certain signals to communicate with sysvinit’s init, but none of them are relevant here. You can’t use them to request an arbitrary runlevel change.
    – Stephen Kitt
    20 hours ago













up vote
3
down vote



accepted







up vote
3
down vote



accepted






With both sysvinit and systemd, shutting the operating system down starts by notifying the init process (the process with pid 1) that the system should shut down (or reboot, or power off).



sysvinit does this by using the /run/initctl FIFO to communicate with init, asking it to switch to the corresponding runlevel. See the init manpage for a brief overview.



systemd supports a variety of ways to do this. Various signals can be used to request a shutdown, reboot, etc., in various flavours; it’s also possible to request this over d-bus (the busctl manpage explains how to explore that).



Once pid 1 has been asked to shut down, it follows its configuration and specification and goes through all the appropriate steps for it. This typically includes notifying all users that a shutdown is in progress, shutting down all the running services (in a managed way with systemd; using shutdown scripts in various forms with sysvinit), syncing the mounted file systems, possibly unmounting them, killing all remaining processes (with the usual TERM then KILL sequence), and finally calling the kernel’s reboot system call with the appropriate parameters.



This describes the general sequence. There are many more twists to all this, including access control (with Polkit), various available hooks, kexec, sudden power-off handling, CtrlAltDel handling... The systemd documentation covers many of these details.






share|improve this answer














With both sysvinit and systemd, shutting the operating system down starts by notifying the init process (the process with pid 1) that the system should shut down (or reboot, or power off).



sysvinit does this by using the /run/initctl FIFO to communicate with init, asking it to switch to the corresponding runlevel. See the init manpage for a brief overview.



systemd supports a variety of ways to do this. Various signals can be used to request a shutdown, reboot, etc., in various flavours; it’s also possible to request this over d-bus (the busctl manpage explains how to explore that).



Once pid 1 has been asked to shut down, it follows its configuration and specification and goes through all the appropriate steps for it. This typically includes notifying all users that a shutdown is in progress, shutting down all the running services (in a managed way with systemd; using shutdown scripts in various forms with sysvinit), syncing the mounted file systems, possibly unmounting them, killing all remaining processes (with the usual TERM then KILL sequence), and finally calling the kernel’s reboot system call with the appropriate parameters.



This describes the general sequence. There are many more twists to all this, including access control (with Polkit), various available hooks, kexec, sudden power-off handling, CtrlAltDel handling... The systemd documentation covers many of these details.







share|improve this answer














share|improve this answer



share|improve this answer








edited 20 hours ago

























answered yesterday









Stephen Kitt

162k24362440




162k24362440












  • Thanks. In manpages.debian.org/stretch/sysvinit-core/…, init also reacts to some signals. Does that mean we can communicate with init by sending some signals instead of using FIFO, asking it to switch to the corresponding runlevel?
    – Tim
    23 hours ago










  • /run/initctl is FIFO not socket. Let me know if I am wrong.
    – Tim
    22 hours ago












  • You can use certain signals to communicate with sysvinit’s init, but none of them are relevant here. You can’t use them to request an arbitrary runlevel change.
    – Stephen Kitt
    20 hours ago


















  • Thanks. In manpages.debian.org/stretch/sysvinit-core/…, init also reacts to some signals. Does that mean we can communicate with init by sending some signals instead of using FIFO, asking it to switch to the corresponding runlevel?
    – Tim
    23 hours ago










  • /run/initctl is FIFO not socket. Let me know if I am wrong.
    – Tim
    22 hours ago












  • You can use certain signals to communicate with sysvinit’s init, but none of them are relevant here. You can’t use them to request an arbitrary runlevel change.
    – Stephen Kitt
    20 hours ago
















Thanks. In manpages.debian.org/stretch/sysvinit-core/…, init also reacts to some signals. Does that mean we can communicate with init by sending some signals instead of using FIFO, asking it to switch to the corresponding runlevel?
– Tim
23 hours ago




Thanks. In manpages.debian.org/stretch/sysvinit-core/…, init also reacts to some signals. Does that mean we can communicate with init by sending some signals instead of using FIFO, asking it to switch to the corresponding runlevel?
– Tim
23 hours ago












/run/initctl is FIFO not socket. Let me know if I am wrong.
– Tim
22 hours ago






/run/initctl is FIFO not socket. Let me know if I am wrong.
– Tim
22 hours ago














You can use certain signals to communicate with sysvinit’s init, but none of them are relevant here. You can’t use them to request an arbitrary runlevel change.
– Stephen Kitt
20 hours ago




You can use certain signals to communicate with sysvinit’s init, but none of them are relevant here. You can’t use them to request an arbitrary runlevel change.
– Stephen Kitt
20 hours ago



Popular posts from this blog

Entries order in /etc/network/interfaces

新発田市

Grub takes very long (several minutes) to open Menu (in Multi-Boot-System)