How to undo shutdown? [duplicate]

Clash Royale CLAN TAG#URR8PPP
up vote
-1
down vote
favorite
This question already has an answer here:
Is it possible to stop a shutdown command?
3 answers
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?
shutdown
marked as duplicate by Jeff Schaller, Romeo Ninov, jimmij, Timothy Martin, G-Man Apr 30 at 20:59
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |Â
up vote
-1
down vote
favorite
This question already has an answer here:
Is it possible to stop a shutdown command?
3 answers
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?
shutdown
marked as duplicate by Jeff Schaller, Romeo Ninov, jimmij, Timothy Martin, G-Man Apr 30 at 20:59
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
Given 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 reachingshutdown.targetthat you aren't telling us about, as in previous questions.
â JdeBP
Apr 30 at 6:41
add a comment |Â
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
This question already has an answer here:
Is it possible to stop a shutdown command?
3 answers
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?
shutdown
This question already has an answer here:
Is it possible to stop a shutdown command?
3 answers
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?
This question already has an answer here:
Is it possible to stop a shutdown command?
3 answers
shutdown
asked Apr 29 at 17:59
neverMind9
22110
22110
marked as duplicate by Jeff Schaller, Romeo Ninov, jimmij, Timothy Martin, G-Man Apr 30 at 20:59
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Jeff Schaller, Romeo Ninov, jimmij, Timothy Martin, G-Man Apr 30 at 20:59
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
Given 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 reachingshutdown.targetthat you aren't telling us about, as in previous questions.
â JdeBP
Apr 30 at 6:41
add a comment |Â
Given 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 reachingshutdown.targetthat you aren't telling us about, as in previous questions.
â JdeBP
Apr 30 at 6:41
Given 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 at 6:41
Given 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 at 6:41
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
1
down vote
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".
add a comment |Â
up vote
0
down vote
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?
add a comment |Â
up vote
0
down vote
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 :-/ ).
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
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".
add a comment |Â
up vote
1
down vote
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".
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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".
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".
answered Apr 29 at 18:47
grog_7
262
262
add a comment |Â
add a comment |Â
up vote
0
down vote
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?
add a comment |Â
up vote
0
down vote
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?
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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?
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?
answered Apr 29 at 19:12
rockower
1145
1145
add a comment |Â
add a comment |Â
up vote
0
down vote
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 :-/ ).
add a comment |Â
up vote
0
down vote
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 :-/ ).
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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 :-/ ).
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 :-/ ).
answered Apr 29 at 20:43
telcoM
10.2k11032
10.2k11032
add a comment |Â
add a comment |Â
Given 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.targetthat you aren't telling us about, as in previous questions.â JdeBP
Apr 30 at 6:41