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

From: Christian Jaeger (christian.jaeger_at_ethlife.ethz.ch)
Date: Tue 13 Apr 2004 - 14:38:03 BST


At 9:52 Uhr +0200 13.04.2004, Enrico Scholz wrote:
>christian.jaeger_at_ethlife.ethz.ch (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
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver


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 Tue 13 Apr 2004 - 14:39:01 BST by hypermail 2.1.3