Hello,
Domain kernel has arch/xen/kernel/reboot.c, which executes shutdown
and halt on request. But one problem is that we have the path and
command options fixed in the kernel, like this:
static char *restart_argv[] = { "/sbin/shutdown", "-r",
"now", NULL };
static char *poweroff_argv[] = { "/sbin/halt", "-p",
NULL };
That is kind of violating the rule: kernel should never enforce the
policy to the user. We can see the problem if for example domU uses
busybox instead of sysvinit: busybox doesnt support "halt -p", so
"xm
shutdown" cannot shutdown the domU.
Should we care enough to fix this problem?
regards,
aq
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> Domain kernel has arch/xen/kernel/reboot.c, which executes > shutdown and halt on request. But one problem is that we have > the path and command options fixed in the kernel, like this: > > > static char *restart_argv[] = { "/sbin/shutdown", "-r", > "now", NULL }; > static char *poweroff_argv[] = { "/sbin/halt", "-p", > NULL }; > > > That is kind of violating the rule: kernel should never > enforce the policy to the user. We can see the problem if for > example domU uses busybox instead of sysvinit: busybox doesnt > support "halt -p", so "xm shutdown" cannot shutdown the domU.Would ''telinit 1'' / ''telinit 6'' work on busybox ? Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7/25/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> > Domain kernel has arch/xen/kernel/reboot.c, which executes > > shutdown and halt on request. But one problem is that we have > > the path and command options fixed in the kernel, like this: > > > > > > static char *restart_argv[] = { "/sbin/shutdown", "-r", > > "now", NULL }; > > static char *poweroff_argv[] = { "/sbin/halt", "-p", > > NULL }; > > > > > > That is kind of violating the rule: kernel should never > > enforce the policy to the user. We can see the problem if for > > example domU uses busybox instead of sysvinit: busybox doesnt > > support "halt -p", so "xm shutdown" cannot shutdown the domU. > > Would ''telinit 1'' / ''telinit 6'' work on busybox ? >Unfortunately telinit is not available in busybox. Here are 2 patches (for -testing and -unstable), in which i replaced shutdown and halt with poweroff and reboot, and executes those without any options. This patch confirms to work with both sysvinit (on Ubuntu) and busybox (ttylinux - without these patch i couldnt shutdown ttylinux with "xm shutdown"). Please apply. Signed-off-by: Nguyen Anh Quynh <aquynh@gmail.com> $ diffstat shutdown.testing.patch reboot.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) $ diffstat shutdown.unstable.patch reboot.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Can''t we just fire off a kernel thread to call sys_reboot and friends directly? It seems unfortunate to have to rely on userspace applications, having gone to the trouble of handling the cmsg in the kernel. Cheers, Mark On Monday 25 July 2005 18:41, aq wrote:> On 7/25/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote: > > > Domain kernel has arch/xen/kernel/reboot.c, which executes > > > > > > shutdown and halt on request. But one problem is that we have > > > the path and command options fixed in the kernel, like this: > > > > > > > > > static char *restart_argv[] = { "/sbin/shutdown", "-r", > > > "now", NULL }; > > > static char *poweroff_argv[] = { "/sbin/halt", "-p", > > > NULL }; > > > > > > > > > That is kind of violating the rule: kernel should never > > > enforce the policy to the user. We can see the problem if for > > > example domU uses busybox instead of sysvinit: busybox doesnt > > > support "halt -p", so "xm shutdown" cannot shutdown the domU. > > > > Would ''telinit 1'' / ''telinit 6'' work on busybox ? > > Unfortunately telinit is not available in busybox. > > Here are 2 patches (for -testing and -unstable), in which i replaced > shutdown and halt with poweroff and reboot, and executes those without > any options. This patch confirms to work with both sysvinit (on > Ubuntu) and busybox (ttylinux - without these patch i couldnt shutdown > ttylinux with "xm shutdown"). Please apply. > > > Signed-off-by: Nguyen Anh Quynh <aquynh@gmail.com> > > > $ diffstat shutdown.testing.patch > reboot.c | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) > > $ diffstat shutdown.unstable.patch > reboot.c | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-)_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 2005-07-25 at 18:47 +0100, Mark Williamson wrote:> Can''t we just fire off a kernel thread to call sys_reboot and friends > directly? It seems unfortunate to have to rely on userspace applications, > having gone to the trouble of handling the cmsg in the kernel.That doesn''t do a graceful shutdown of running processes, does it? Jeremy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > Can''t we just fire off a kernel thread to call sys_reboot and friends > > directly? It seems unfortunate to have to rely on userspace > > applications, having gone to the trouble of handling the cmsg in the > > kernel. > > That doesn''t do a graceful shutdown of running processes, does it?Hmmmm, I suppose not. Ah well, I think I''ll withdraw my previous statement as I can''t think of another way to do this right now :-) It''d be nice if Linux had a generic way of communicating a reboot request to userspace. It ought to be useful on other VMMs - maybe this is something for Rik''s common infrastructure wishlist? Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 25 Jul 2005, Mark Williamson wrote:> It''d be nice if Linux had a generic way of communicating a reboot > request to userspace. It ought to be useful on other VMMs - maybe this > is something for Rik''s common infrastructure wishlist?How about simply reusing whatever signal is sent to init when ctrl-alt-del is pressed on PCs ? -- The Theory of Escalating Commitment: "The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself." -- Joseph Stiglitz, Nobel Laureate in Economics _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Jul 25, 2005 at 02:13:25PM -0400, Rik van Riel wrote:> On Mon, 25 Jul 2005, Mark Williamson wrote: > > > It''d be nice if Linux had a generic way of communicating a reboot > > request to userspace. It ought to be useful on other VMMs - maybe this > > is something for Rik''s common infrastructure wishlist? > > How about simply reusing whatever signal is sent to init > when ctrl-alt-del is pressed on PCs ?SIGINT That''s not a good idea though, if somebody put nothing in the ctrlaltdel action, then it''s not going to do anything. -- Vincent Hanquez _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7/26/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:> > > Can''t we just fire off a kernel thread to call sys_reboot and friends > > > directly? It seems unfortunate to have to rely on userspace > > > applications, having gone to the trouble of handling the cmsg in the > > > kernel. > > > > That doesn''t do a graceful shutdown of running processes, does it? > > Hmmmm, I suppose not. Ah well, I think I''ll withdraw my previous statement as > I can''t think of another way to do this right now :-) >actually what you suggested is in use now ;-). firstly, the code use daemonize() to become kernel thread, then execute userspace code (shutdown/poweroff/halt...). if that failed (for example in case there is no such userspace binary), sys_reboot is called. i dont see why we try to call userspace comand first, then fail thru to sys_reboot(). why just call sys_reboot()? regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Monday 25 July 2005 19:13, Rik van Riel wrote:> On Mon, 25 Jul 2005, Mark Williamson wrote: > > It''d be nice if Linux had a generic way of communicating a reboot > > request to userspace. It ought to be useful on other VMMs - maybe this > > is something for Rik''s common infrastructure wishlist? > > How about simply reusing whatever signal is sent to init > when ctrl-alt-del is pressed on PCs ?Sounds good. Something like this must be done for smart power button handling in the ACPI code, so that might be a good place to refer to. It''d be nice if we could communicate the difference between a reboot and a halt request though. Alternatively, the tools could just remember what we "meant" the restart to do and do the right thing when the domain quits. Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> actually what you suggested is in use now ;-). firstly, the code use > daemonize() to become kernel thread, then execute userspace code > (shutdown/poweroff/halt...). if that failed (for example in case there > is no such userspace binary), sys_reboot is called.Yeah, I just looked at the code and realised I was just spouting rubbish earlier :-)> i dont see why we try to call userspace comand first, then fail thru > to sys_reboot(). why just call sys_reboot()?As Jeremy said, the reboot command does rather more than just call sys_reboot. The sys_reboot call means "really reboot now", without doing the nice things init does (unmounting filesystems, stopping processes politely, etc). I think there must be another way of achieving this effect without exec-ing things, though. Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Vincent Hanquez wrote:>On Mon, Jul 25, 2005 at 02:13:25PM -0400, Rik van Riel wrote: > > >>On Mon, 25 Jul 2005, Mark Williamson wrote: >> >> >> >>>It''d be nice if Linux had a generic way of communicating a reboot >>>request to userspace. It ought to be useful on other VMMs - maybe this >>>is something for Rik''s common infrastructure wishlist? >>> >>> >>How about simply reusing whatever signal is sent to init >>when ctrl-alt-del is pressed on PCs ? >> >> > >SIGINT > >That''s not a good idea though, if somebody put nothing in the ctrlaltdel >action, then it''s not going to do anything. > >Aren''t we trying to something a bit unnatural here? Clearly, shutting down is something best done from userspace. Maybe it''s time to start thinking about domU tools for Xen userspace? If the XenStore API can be accessible via userspace we could easily write some patches (or special daemons) that could do this sort of stuff. Might be particularily useful if we want to provide more sophisticated stuff in the future. Not something for Xen 3.0 but might be interesting for 3.1.x. Thoughts? Am I crazy? :-) Regards, Anthony Liguori _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Jul 26, 2005 at 03:26:34AM +0900, aq wrote:> i dont see why we try to call userspace comand first, then fail thru > to sys_reboot(). why just call sys_reboot()?because sys_reboot doesn''t do: - a clean shutdown of all processes of the machines. - unmount partitions. - sync data to disk. - problably some more reasons. -- Vincent Hanquez _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 25 Jul 2005, Vincent Hanquez wrote:> On Mon, Jul 25, 2005 at 02:13:25PM -0400, Rik van Riel wrote:> > How about simply reusing whatever signal is sent to init > > when ctrl-alt-del is pressed on PCs ? > > SIGINT > > That''s not a good idea though, if somebody put nothing in the ctrlaltdel > action, then it''s not going to do anything.But isn''t that exactly what we want ? A userspace configurable way to trigger a system reboot. -- The Theory of Escalating Commitment: "The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself." -- Joseph Stiglitz, Nobel Laureate in Economics _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > > How about simply reusing whatever signal is sent to init when > > > ctrl-alt-del is pressed on PCs ? > > > > SIGINT > > > > That''s not a good idea though, if somebody put nothing in the > > ctrlaltdel action, then it''s not going to do anything. > > But isn''t that exactly what we want ? A userspace configurable > way to trigger a system reboot.I kind of like this approach, but it does mean that we can''t distinguish between a poweroff and a reboot. Do we care? As I recall, the current approach was copied from one of the other Linux architectures. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Jul 25, 2005 at 08:48:12PM +0100, Ian Pratt wrote:> > > > > How about simply reusing whatever signal is sent to init when > > > > ctrl-alt-del is pressed on PCs ? > > > > > > SIGINT > > > > > > That''s not a good idea though, if somebody put nothing in the > > > ctrlaltdel action, then it''s not going to do anything. > > > > But isn''t that exactly what we want ? A userspace configurable > > way to trigger a system reboot. > > I kind of like this approach, but it does mean that we can''t distinguish > between a poweroff and a reboot. Do we care? > > As I recall, the current approach was copied from one of the other Linux > architectures.Additionally modern init supports "powerfail" which is the action to be triggered when the power fails due to UPS. Using powerfail and ctrlaltdel as the 2 actions would provide the different triggers needed for shutdown. It would allow for userspace configurability very easily. Though the original problem could probably be solved just by changing the hard coded user callouts to "/sbin/reboot" and "/sbin/poweroff", which I believe both exist in busybox (or can both exist). Given that other things like hotplug and modprobe are directly called out from the kernel, this might be an ok approach. -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 25 Jul 2005, at 21:18, Sean Dague wrote:> Additionally modern init supports "powerfail" which is the action to be > triggered when the power fails due to UPS. Using powerfail and > ctrlaltdel > as the 2 actions would provide the different triggers needed for > shutdown. > It would allow for userspace configurability very easily. > > Though the original problem could probably be solved just by changing > the > hard coded user callouts to "/sbin/reboot" and "/sbin/poweroff", which > I > believe both exist in busybox (or can both exist). Given that other > things > like hotplug and modprobe are directly called out from the kernel, this > might be an ok approach.The latter approach sounds good to me. The commands have obvious names, have sane default behaviour on most distros, can be easily overridden/defined if necessary. I''ll go with that. Much better than hooking into all that acpi crap, or an approach that would force users to install xen-specific things in a domU for such a trivial action. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Rumor has it that on Mon, Jul 25, 2005 at 08:48:12PM +0100 Ian Pratt said:> > > > > How about simply reusing whatever signal is sent to init when > > > > ctrl-alt-del is pressed on PCs ? > > > > > > SIGINT > > > > > > That''s not a good idea though, if somebody put nothing in the > > > ctrlaltdel action, then it''s not going to do anything. > > > > But isn''t that exactly what we want ? A userspace configurable > > way to trigger a system reboot. > > I kind of like this approach, but it does mean that we can''t distinguish > between a poweroff and a reboot. Do we care? >yes, I think there''s a difference... If I halt a guest I don''t expect it to reboot.> As I recall, the current approach was copied from one of the other Linux > architectures.Could these be new hotplug events? That would get them out to userspace where they would presumably be configurable. Cheers, Phil> > Ian > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Philip R. Auld, Ph.D. Egenera, Inc. Software Architect 165 Forest St. (508) 858-2628 Marlboro, MA 01752 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 25 Jul 2005, at 21:48, Mark Williamson wrote:>> As I recall, the current approach was copied from one of the other >> Linux >> architectures. > > Personally I''d vote for signalling userspace rather than shelling a > command > but I''ll leave it up to whoever wants to write the code ;-)Exec''ing a userspace program is a recognised method for signalling userspace these days, I believe. That''s how hotplug works, certainly, and it does have the benefit of ''obviousness''. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
<snip signalling to init>> I kind of like this approach, but it does mean that we can''t distinguish > between a poweroff and a reboot. Do we care?The tools could perhaps distinguish: they just have to remember if you asked for a reboot or a halt, then do the right thing. It seems unlikely you''d want to ask for "reboot" on the command line but really have the domain halt.> As I recall, the current approach was copied from one of the other Linux > architectures.Personally I''d vote for signalling userspace rather than shelling a command but I''ll leave it up to whoever wants to write the code ;-) Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 25 Jul 2005, Mark Williamson wrote:> > As I recall, the current approach was copied from one of the other Linux > > architectures. > > Personally I''d vote for signalling userspace rather than shelling a command > but I''ll leave it up to whoever wants to write the code ;-)A hotplug event might work too... -- The Theory of Escalating Commitment: "The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself." -- Joseph Stiglitz, Nobel Laureate in Economics _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Philip R Auld <pauld@egenera.com> writes:> > I kind of like this approach, but it does mean that we can''t distinguish > > between a poweroff and a reboot. Do we care? > > yes, I think there''s a difference... If I halt a guest I don''t expect > it to reboot.Especially if you want to reboot the (physical) machine with something like "xm shutdown -a -w && reboot" in domain0 ... Gerd -- panic("it works"); /* avoid being flooded with debug messages */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel