From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Sun 16 Nov 2003 - 12:18:59 GMT
On Sun, Nov 16, 2003 at 07:13:48AM -0500, Allen D. Parker II wrote:
> I'm no programmer, but I do believe, it would be pretty nice if the "owner"
> of a context (fake "root" user) could halt/reboot *their* vserver via
> /sbin/init, /sbin/reboot or /sbin/halt. It'd be nice to have a way to pass
> messages *securely* back to something on the outside that would do a context
> id check (ie where's it coming from and what's it trying to apply those
> changes to) and then if everything checks out, does the vserver
> <context-id-resolves-to-this-name> start/stop/restart. I personally can't
> figure out what to do about this *other* than figure out what the hell keeps
> calling it and removing it from the "halt" script (the same one that kills
> errant processes on vserver <vsname> stop).
hey cool idea!
maybe that was the reason I included it in the
latest development release vs1.1.3 ;)
if you give it a try, and experiment a little
with the reboot userspace helper, please let
me know how it works for you ...
> Just my $.02
> Allen Parker
> > -----Original Message-----
> > From: vserver-admin_at_list.linux-vserver.org [mailto:vserver-
> > admin_at_list.linux-vserver.org] On Behalf Of Herbert Poetzl
> > Sent: Saturday, November 15, 2003 7:07 AM
> > To: Allen Parker
> > Cc: vserver_at_list.linux-vserver.org
> > Subject: Re: [Vserver] hrm... another odd thing.. /dev/initctl?
> > On Sat, Nov 15, 2003 at 03:35:23AM -0500, Allen Parker wrote:
> > > init: timeout opening/writing control channel /dev/initctl
> > on a 'normal' server, init and telinit are often the
> > same binary, and the 'init' process knows that it is
> > init by verifying that it's pid equals 1 ...
> > when init is started, it opens a pipe, which reads
> > the commands given by telinit and halt, poweroff, etc.
> > possible causes for this message therefor are:
> > - init/telinit is called but not as pid == 1
> > - reboot, halt, poweroff are called without -f
> > - init is started as 'faked' pid 1 but this
> > doesn't work as expected yet ...
> > possible solutions:
> > - add some userspace tool outside the vserver
> > which opens/reads the pipe and acts accordingly
> > - find the 'bad' invocation and 'improve' it
> > or remove it, if not required
> > - demonstrate that it is a vserver misbehaviour
> > which requires some code change ;)
> > HTH,
> > Herbert
> > > util-vserver-0.24 kernel-2.4.22-vs1.00
> > >
> > > Allen Dale Parker
> > > allenp_at_efn.org
> > >
> > > "ego sum ens ompnipotens"
> > >
> > >
> > > _______________________________________________
> > > Vserver mailing list
> > > Vserver_at_list.linux-vserver.org
> > > http://list.linux-vserver.org/mailman/listinfo/vserver
> > _______________________________________________
> > Vserver mailing list
> > Vserver_at_list.linux-vserver.org
> > http://list.linux-vserver.org/mailman/listinfo/vserver
> Vserver mailing list
Vserver mailing list