-1

I have searched how Linux reboot process work and everywhere found only the booting/start-up process. Suppose for a illegal reboot how machine recover my running processes/services (for example, if db is running and I have forcefully restarted the machine) ?

Subarno Saha
  • 67
  • You seem to be talking about two different things: Rebooting using something like a reboot command, and "forcefully restarting" ("illegal reboot"?), i.e. pulling the power plug and then starting the machine again. Did I understand you correctly? – Kusalananda Oct 16 '19 at 05:26
  • Yes . I have questioned both "reboot" and "forceful reboot" – Subarno Saha Oct 16 '19 at 05:49
  • 1
    When the machine starts it doesn't know whether it was shut down nicely or "forcefully", so it can't have two different procedures. Linux as such doesn't try to recover anything, it just starts. Individual processes may try to detect that they weren't terminated as they would have liked (but they don't care what happened since they were running, i.e. whether there has been a reboot), and try to restore their state, including subprocesses. But there are so many processes that might do this, that you'll need to be more specifiic. – Henrik supports the community Oct 16 '19 at 05:55
  • @Henrik but what are the exact processes/procedures for Reboot ? When machine starts after completing health checkup it completes other procedures(ex, MBR check etc). – Subarno Saha Oct 16 '19 at 07:14
  • There are not distinct procedures for reboot that are not specific to a given process. – Henrik supports the community Oct 16 '19 at 08:15
  • 1
    Everything you found about the boot process applies after a reboot. Look into init systems; it’s likely you’re using systemd (since most popular Linux distros use systemd). But since you talk about MBR you might want to go earlier: look into grub, and the BIOS settings for your specific machine. Really your question is impossibly vague but maybe this comment will help you find what you seek. – Wildcard Oct 16 '19 at 08:22
  • In the end you touch the question of tool chain, almost. Beacause, with linux et al., you can automatically start a process that can do everything including low level access to trigger a restart of itself or of another process. In the end. I have commented in the existing answer. You ask for things like CTRL-ALT-DEL and what that does? Please tell me, I find this very interesting. And important, for amateur sysadmins like me. –  Oct 16 '19 at 10:51
  • Possible duplicate of How does the system shutdown of a linux kernel work internally? – arif Oct 18 '19 at 08:18

1 Answers1

5

A controlled reboot is basically a normal shutdown, but instead of turning off the power at the end, the hardware reset procedure is applied so that the firmware takes over and restarts the system, essentially just like when powering up the system. (The firmware may choose to shorten or omit some of the tests if it can detect that the system is not powering up from a "cold" state.)

There is no system-wide mechanism for automatically storing the system state: if you had e.g. configured network interfaces with ifconfig or ipcommands but not edited the appropriate configuration files to make the configuration persistent, that configuration will be lost at any reboot. If you had started any services manually (e.g. service <something> start or systemctl start <something>) but not also enabled them to start automatically at boot (e.g. chkconfig <something> on or systemctl enable <something>), the service will not be automatically started after a reboot.

Some system administration tools like NetworkManager will automatically update the configuration files to persist any configuration changes unless you specifically tell it not to; others will require one action to actually make a change now and another to make the change permanent.

Some desktop environments may try and maintain the state of the user session, so that when a user logs out in a controlled fashion with some GUI programs still running, the same GUI programs will be started automatically at next login. But there is no guarantee that those programs themselves will maintain their internal state: some programs might do it, others won't. Text-based programs within a GUI environment may treat a GUI logout as equivalent of a remote SSH user suddenly losing the network connection: in particular, text editors like vi will usually save any unsaved data in a special backup file, so that the interrupted work is not lost.

If the system is shutdown in a forceful way (e.g. by pressing a hardware reset button or by removing the power cord), everything that is stored only in RAM will be lost. A boot-time filesystem check will detect that filesystems were not properly mounted: journalling filesystems will usually execute a journal recovery automatically to keep the filesystem metadata internally consistent, but unless the data is also journalled, you may find that some data did not actually reach the disk (this may appear as strings of repeated \000 in log files, as the last block allocated but not written has only zero bytes in it). Databases may also need to execute some sort of consistency recovery actions after a forceful shutdown.

A normal, controlled shutdown (or reboot) involves:

  • sending a HUP signal to all processes belonging to users' login sessions, so that they get the opportunity to do whatever they need to do before exiting (e.g. saving a backup of any unsaved work)
  • shutting down system services in a sensible order, so that services that are dependent on other services are shut down before the services they're depending on. For things like big databases, this can be a pretty big task all on its own.
  • if there are users' processes or system services that are not shutting down in a timely manner, sending them first a normal TERM signal, giving them a bit more time, and ultimately sending them a KILL signal so that the processes get every chance to either complete or roll back any unfinished business they might have. But ultimately, the processes must be terminated so that all their files can be closed, to allow the filesystems to unmount cleanly.
  • after the number of processes left running is cut back to the minimum necessary, unmounting any network-based filesystems in a controlled manner, making sure that any cached write operations are completed before unmounting.
  • shutting down any services related to accessing network filesystems
  • completing any cached write operations to local disks, then unmounting those disks, except the root filesystem which is usually just switched to read-only mode instead. (Modern filesystems may record the fact that they have been properly unmounted in an error-free state and there will be no need for recovery actions before mounting them again.)
  • finally, the kernel is told to send the hardware signal to either power off or to reset the system, as appropriate

In a properly-configured system, all this is taken care by the init subsystem (which may be systemd, classic SysVinit, or something else) when you use shutdown -h or shutdown -r commands.

If you use reboot -f, it means that you're intentionally skipping all but the last of the shutdown steps mentioned above.

telcoM
  • 96,466
  • This is a good expl. of why you have to differentiate. And in fact you say there are different ways tu shut down a system, and to store the settings as configurations...AND when you think of kexec . I recommend a technical condensation of your answer. sessions, dameons, init/initscripts. NOT the details! The precise terminolgy with definitions, explanations and examples. –  Oct 16 '19 at 10:40
  • Even systemd's initrd at shutdown is just a detail. Just define what a "clean" shutdown is, how to make one. If you have e.g. a DATABASE running. –  Oct 16 '19 at 10:42