From: Axel Thimm <Axel.Thimm@physik.fu-berlin.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Remotely rebooting a machine with state 'D' processes, how?
Date: Sat, 11 Aug 2001 09:26:23 +0200 [thread overview]
Message-ID: <20010811092623.A4877@bonzo.nirvana> (raw)
In-Reply-To: <20010810231906.A21435@bonzo.nirvana> <200108102159.f7ALxb908284@penguin.transmeta.com>
In-Reply-To: <200108102159.f7ALxb908284@penguin.transmeta.com>; from torvalds@transmeta.com on Fri, Aug 10, 2001 at 02:59:37PM -0700
On Fri, Aug 10, 2001 at 02:59:37PM -0700, Linus Torvalds wrote:
> In article <20010810231906.A21435@bonzo.nirvana> you write:
> > How can I reboot a stuck machine remotely, when there are uninterruptable
> > processes arround? shutdown -r, reboot [-n] [-f], telinit 6 do not give
> > the intended results. Localy I can use Alt-SysRq-S/U/B, but what if I
> > still have a remote ssh connection and don't want to have to get to the
> > machines location?
> >
> > Of course the real problem are the processes themselves, but being able to
> > revive a machine is also nice ;)
> You have to use the reboot() system call directly as root, with the proper
> arguments to make it avoid doing even any sync. See man 2 reboot for
> details.
Would there be a way to also simulate the effects of Alt-SysRq-S and
Alt-SysRq-U? A simple sync falls also into D-state, Alt-SysRq-S does not, as
far as I have had to use it.
Would an `emergency-reboot' binary that calls these three kernel calls be
possible and also good-to-have if it's not a too bad idea?
Is there a way to have this automated in some kind of a kernel software
watchdog? Given certain conditions (like processes in D-state for longer than
a specified time) the kernel might first try to call a userland-reboot and
this timing out the kernel might use the sync;umount;reboot procedure of
Alt-SysRq-S/U/B.
But even when I write this I realize the security hole potentials. If someone
could simulate the watchdog conditions for a reboot, he might be able to have
this machine reboot all the time.
--
Axel.Thimm@physik.fu-berlin.de
next prev parent reply other threads:[~2001-08-11 7:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-10 21:19 Remotely rebooting a machine with state 'D' processes, how? Axel Thimm
2001-08-10 21:57 ` Brian
2001-08-10 21:59 ` Linus Torvalds
2001-08-10 22:50 ` Herbert Xu
2001-08-10 22:55 ` Andi Kleen
2001-08-10 23:05 ` Herbert Xu
2001-08-10 22:57 ` Robert Love
2001-08-10 22:58 ` Linus Torvalds
2001-08-10 23:50 ` Herbert Xu
2001-08-11 0:04 ` Mike Fedyk
2001-08-19 4:02 ` Troy Benjegerdes
2001-08-11 0:06 ` Chris Abbey
2001-08-10 22:58 ` Chris Wedgwood
2001-08-11 7:26 ` Axel Thimm [this message]
2001-08-11 11:28 ` Kai Henningsen
-- strict thread matches above, loose matches on Subject: below --
2001-08-10 23:25 Ricardo Galli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010811092623.A4877@bonzo.nirvana \
--to=axel.thimm@physik.fu-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.