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 [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
