[EMAIL PROTECTED] (Christian Jaeger) writes:
1.- Not a problem of the utils but of my setup: I have a setup where the vserver tools are inside a chroot, not on the plain host. This is because I want to keep woody on the host, but the alpha tools only compile on sarge/sid.
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:
checking whether g++ is a C++ compiler... no
configure: WARNING: *** some programs will not be built because a C++ compiler is lacking
checking whether gcc is a C99 compiler... no
configure: WARNING: *** some programs will not be built because a C99 compiler is lacking
g++ is: g++-2.95: /usr/bin/g++-2.95
checking whether to enable dietlibc... no (detected)
The result is this:
Use dietlibc: no (you have been warned)
Build C++ programs: no (affected: vbuild, vcheck)
Build C99 programs: no (affected: vunify, vcopy)
Available APIs: legacy,compat,v11,v13,fscompat,oldproc,oldutspipe. 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? see also Herbert's reply to my other mail; I'll ask in irc. BTW it would be nice if the vserver user could still set his default runlevel as usual in /etc/inittab, with the current approach this doesn't work, but the host admin has to set /etc/vservers/foo/apps/init/runlevel instead which I think is the wrong place.
> (The rather strange thing about this is, that reboot -f usually does > circumvent the normal shutdown process, but in this vserver case, itwill 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? I've tried right now, but have not had a monitor attached to the machine so can't say for sure what it looked like.)
> 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.
Do I understand you right that you say, "reboot -f" issues one LINUX_REBOOT_CMD_RESTART (which is translated into "restart2" which is being ignored) and one LINUX_REBOOT_CMD_CAD_OFF (which is translated into "restart" which triggers the vserver shutdown)? If so, then you haven't answered why later in the process, right at the begin of the new *start* of the vserver, the kernel calls vshelper *again* two times, once with each of the above arguments.
Thanks, Christian. _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
