[EMAIL PROTECTED] (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 there. >> > (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 >> >> | reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART) = 0 >> | reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF) = 0 >> >>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' messages) Enrico _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver