About this list Date view Thread view Subject view Author view Attachment view

From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Wed 14 Apr 2004 - 10:05:34 BST

christian.jaeger_at_ethlife.ethz.ch (Christian Jaeger) writes:

>>Hmm, I tested it on plain woody and it built there. Which errors do
>>you get?
> Well, I had built and installed the .201 version on woody before, but
> couldn't use vunify; same thing with .207:

Ah ok, this behavior is expected. Since vunify is linked statically
against dietlibc (when available), it should be no problem to use the
sarge/sid compiled version on woody.

>>pipe. So, best solution would be probably a final initscript which
>>calls a reboot(2) wrapper. I will see what I can do there, but this
>>will be a very distribution specific task.
> Why should it be a final one? Why not just do something like "vserver
> foo enter /sbin/init"? wouldn't that work?

Try it yourself:

| echo plain >/etc/vservers/<id>/apps/init/style

But at least with RH/Fedora, this will do lots of unwanted actions at
startup (invoking fsck, setting hwclock, calling depmod, loading USB
modules...). I never tried Debian; perhaps it is solved more cleanly

>> > (The rather strange thing about this is, that reboot -f usually does
>> > circumvent the normal shutdown process, but in this vserver case, it
>>> will still shut down the vserver cleanly (wrong "semantics").)
>>I am using vshelper in combination with fakeinit vservers only. There,
>>sending SIGINT to init invokes the shutdown sequence and last action is
>>a reboot(2).
> (Not sure we are talking about the same thing - I *think* that if you
> issue a "reboot -f" on a plain non-vserver host, the machine is just
> reset'ed without any clean shutdown; am I wrong?

When *not* using an init process (e.g. minit, SysV init), you have to
invoke the shutdown sequence manually. But when doing this, the 'reboot'
syscall will probably never be invoked by the initscripts since the
called 'halt' or 'reboot' command relies on the init process.

So within a vserver you have either
* to call the usual 'init' (probably in combination with fakeinit) and
  to fix the low-level init/shutdown scripts, or
* to invoke the start-/shutdown sequence manually and to execute the
  'reboot' syscall finally

>> > 4.- Rather cosmetic, but it might interest you: the vshelper is
>> > triggered twice for each argument (four times in total) for one
>>> "reboot -f":
>>'reboot -f' does
>>The CMD_CAD_OFF is not handled explicitly by the kernel and translated
>>to 'restart' therefore.
>>I do not know why 'restart2' will be invoked; this seems to be implicated
>>by the kernel and 'vshelper' ignores it completely.

Ah ok, I was wrong...

CMD_RESTART is translated to 'restart' and 'CAD_OFF' to 'restart2'. The
second invocation was caused by 'vserver ... stop' which executes a
shutdown-script which calls 'reboot' in turn.

Since regular vshelper information will be destroyed before starting the
shutdown scripts, this does not cause problems (that's why you get the

| 'vshelper' not configured for xid '49169'


Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 14 Apr 2004 - 10:07:11 BST by hypermail 2.1.3