-1

If Linux shuts down, but the computer stays in terminal, I can still print the sysRq help, but no longer enter commands.

Is there any way to escape that and undo shutdown while circumventing the Linux death sin, called reb***ing?

neverMind9
  • 1,690
  • Given https://unix.stackexchange.com/questions/440229/ and the fact that on PC/AT-alike and PC98-alike systems there no such thing as "computer in terminal" (there being a display adapter, that is either in text or graphics mode), I suspect that a lot of important information is missing from this question. For all we know, systemd has put up messages about already reaching shutdown.target that you aren't telling us about, as in previous questions. – JdeBP Apr 30 '18 at 06:41

3 Answers3

1

You can cancel a pending shutdown with: 

shutdown -c

However, this assumes that the initial shutdown command was given with a time interval that isn't "+0" or "now".

grog_7
  • 26
  • 2
0

You can cancel a shutdown with shutdown -c or by hitting just pressing Ctrl+C

This seems like a repeat of this question. Is it possible to stop a shutdown command?

rockower
  • 199
0

If there is no longer any process running that would handle a login attempt (i.e. getty on the console or serial port, or sshd or similar for network connections), then there is very little you can do.

If there is a chance that the init would still be providing a getty process for the console, but the current holder of the console has hung for some reason, you might try Alt-SysRq-k to kill the hung process and hope that init will start a new one for you. But if you've ended up in that state at the tail end of a shutdown, it might not help, as init has already stopped the gettys and not starting any new ones.

The talk of rebooting being a "death sin" is a bit of hyperbole aimed to head off bad habits that some new Linux users may have inherited from their previous operating systems. There is a time and place for everything, including a hard reboot. If you're reasonably sure that there are no other options, then so be it: a large uptime is usually not a goal per se, but a side effect of tight SLAs. And if you have a tight SLA, you want to quickly investigate what has gone wrong, and then do whatever it takes to get the system back up and running ASAP. Once that's done, you can dig into logs and crash dumps to try and find out the root cause and if possible, prevent it from happening again.

I'we worked as enterprise Linux/Unix sysadmin for almost 20 years now. During that time, I've seen quite a few systems so hopelessly wedged that the only solution was to reboot them. Sometimes the reason was broken hardware; other times, an application with a memory leak, or an application acting like a fork bomb when a database connection was not available (a tiny bug in error handling code :-/ ).

telcoM
  • 96,466