Re: [Vserver] reboot does not work with util-vserver-0.29.207
[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
Re: [Vserver] reboot does not work with util-vserver-0.29.207
[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? 2.- As you can see from the above script, I had to change the order of the arguments to make it work. Before that, vshelper complained about I see. The kernel API changed between 1.2x and 1.3/1.90. Fixed in CVS. No responsible vserver found for xid 'restart2' (restart2); aborting... 3.- Only reboot -f does seem to work in debian, shutdown -f now, halt etc are just complaining about missint /dev/initctl and stop. Why is there no initctl if there is an init process running? Are you sure that you mean an init process within the vserver? 'ps' shows a *bogus* init from host-ctx which does not have a /dev/initctl 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. (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). 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. Thx for your report Enrico ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] reboot does not work with util-vserver-0.29.207
At 9:52 Uhr +0200 13.04.2004, Enrico Scholz wrote: [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,olduts 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? 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, 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? 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
Re: [Vserver] reboot does not work with util-vserver-0.29.207
At 9:52 Uhr +0200 13.04.2004, Enrico Scholz wrote: I guess, 'tcpserver' closes standard input (fd 0) after creating the sockets. When fd 0 is closed at program startup, the newly created socket will get fd 0 and be closed. Good guess, your advice has helped. Thanks, Christian ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] reboot does not work with util-vserver-0.29.207
There's one more issue: after rebooting a vserver running sarge, tcpserver (qmail) eats 100% cpu. this only happens when rebooting it from inside (using reboot -f), not when I vserver foo restart manually from the host. strace shows this (looping): rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0 accept(0, 0xb878, [16]) = -1 EBADF (Bad file descriptor) A restart of a vserver running woody (also using reboot -f) does not show this strange behaviour of tcpserver. Christian. ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
