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

From: Bjoern Steinbrink (bjoern.steinbrink_at_isp4p.net)
Date: Sat 25 Dec 2004 - 16:41:47 GMT


On 2004.12.25 17:00:48 +0100, Gilles wrote:
> Hello.
>
>
> I use Debian GNU/Linux with kernel 2.6.7.
>
> [Because of the incompatibilities between kernel patch and
> vserver tools, I compiled a "vanilla" kernel patched with
> "patch-2.6.7-vs1.9.2-rc10.diff".]

If possible update ;) As 2.6.10 is out i guess vs1.9.4 is near...

>
> I then created a bare-bone vserver using the method indicated
> in "http://linux-vserver.org/alpha+util-vserver", namely with
> a command like:
>
> # vserver template build -m debootstrap -context 10 -ip 192.168.1.1 -dev eth0 -- -d sarge
>
> [I uninstalled all Debian packages related to vserver. I compiled
> the alpha-util from "util-vserver-0.30.196.tar.bz2" and installed
> in "/usr/local/util-vserver/".]
>
>
> Starting the newly created vserver:
>
> # /usr/local/util-vserver/sbin/vserver template start
>
> the output is:
> -----
> Starting system log daemon: syslogd.
> Starting kernel log daemon: klogd.
> Starting MTA: exim4.
> Starting internet superserver: inetd.
> Starting deferred execution scheduler: atd.
> Starting periodic command scheduler: cron.
> -----
>
> which seems fine.
>
>
> But, when I enter it:
>
> # /usr/local/util-vserver/sbin/vserver template enter
>
> the output is:
> -----
> mesg: /dev/pts/457: Operation not permitted
> -----
>
> How can I avoid that error?
>

mesg tries to modify the pty's permissions, but linux-vserver protects
ptys, i.e. context A can not modify permissions of a pty that belongs to
context B. Problem: On "vserver xxx enter" you don't get a new pty, so
you're still using a pty that belongs to context 0 and the error
appears. Three possibilities:
a) ignore the error
b) change the pty's permissions before entering the vserver (f.e. "su -"
and "mesg y" should do that)
c) use a ssh connection instead of "vserver xxx enter"

>
> Inside the vserver, I tried the "ps" command, which returned:
> -----
> Error: /proc must be mounted
> To mount /proc at boot you need an /etc/fstab line like:
> /proc /proc proc defaults
> In the meantime, mount /proc /proc -t proc
> -----
>
> and this is the contents (which was created automatically) of my
> "/usr/local/util-vserver/etc/vservers/template/fstab" file:
> -----
> none /proc proc defaults 0 0
> none /tmp tmpfs size=16m,mode=1777 0 0
> none /dev/pts devpts gid=5,mode=620 0 0
> -----
>
> Nevertheless, _within_ the vserver, "/etc/fstab" is empty.
> I tried the suggestion above:
>
> vs:/# mount /proc /proc -t proc
>
> which resulted in:
> -----
> mount: permission denied
> -----
>
> So, what should I do here?
>

See http://linux-vserver.org/Proc-Security

>
> While the vserver was running (within which I hadn't installed
> _any_ "user" program), the CPU was 99%-100% busy!
> I noticed that thanks to the "gkrellm" monitor, since "top" didn't
> indicate anything special.
> I also tried to run "vtop" (on the host system) but _nothing_ showed
> up in the terminal window.
> The help for the command is not very helpful:
> -----
> top: procps version 3.2.1
> usage: top -hv | -bcisS -d delay -n iterations [-u user | -U user] -p pid [,pid ...]
>
> -----
>

That's a problem with signaling in that vserver version, in your case
triggered by klogd.

>
> Then, when I stop the vserver:
>
> # /usr/local/util-vserver/sbin/vserver template stop
>
> the output is:
> -----
> Stopping periodic command scheduler: cron.
> Stopping MTA: exim4.
> Stopping internet superserver: inetd.
> Saving the System Clock time to the Hardware Clock...
> hwclock is unable to get I/O port access: the iopl(3) call failed.
> Hardware Clock updated to Sat Dec 25 14:26:02 UTC 2004.
> Stopping deferred execution scheduler: atd.
> Stopping kernel log daemon: klogd.
> Stopping system log daemon: syslogd.
> Sending all processes the TERM signal...mount: permission denied
> killall5: mount returned non-zero exit status
> killall5: /proc not mounted, failed to mount.
> done.
> Sending all processes the KILL signal...mount: permission denied
> killall5: mount returned non-zero exit status
> killall5: /proc not mounted, failed to mount.
> done.
> Saving random seed...done.
> Unmounting remote and non-toplevel virtual filesystems...done.
> Deconfiguring network interfaces...done.
> Deactivating swap...umount: none: not found
> umount: /tmp: must be superuser to umount
> done.
> Unmounting local filesystems...umount: none: not found
> umount: /tmp: must be superuser to umount
> umount: /dev/hdv1: not found
> umount: /: not mounted
> done.
> mount: permission denied
> Rebooting... ifdown: shutdown eth0: Permission denied
> ifdown: shutdown br0: Permission denied
> ifdown: shutdown dummy0: Permission denied
> ifdown: shutdown dummy1: Permission denied
> -----
>
> Why does "umount" fail?

Because you're not allowed to "umount" from within a vserver.

> What is this "/dev/hdv1" (which is, rightly, not found)?
> Why does "ifdown" try to shutdown the interfaces (other
> than "eth0")?

see /etc/init.d/reboot . reboot is called with -i as command line
switch, causing it to try to shutdown all interfaces.

>
> [Luckily the CPU load went back down to 1%-3% ;-)]

Yeah, klogd died ;)

>
> So, many questions that seem to reveal some failure of
> the default setup on Debian systems?

Removing the hardware dependent runlevel entries is still your task ;)

HTH
Bjoern
_______________________________________________
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 Sat 25 Dec 2004 - 16:42:18 GMT by hypermail 2.1.3