On Wednesday 13 October 2004 16:32, Herbert Poetzl wrote: > On Wed, Oct 13, 2004 at 12:16:16PM +0200, Christian Mayrhuber wrote: > > On Wednesday 13 October 2004 06:35, David MacKinnon wrote: > > > Gregory (Grisha) Trubetskoy wrote: > > > > > > > > > > > I had something similar happen, but then it turned out the problem was > > > > with my config. I figured it out by inserting an occasional echo > > > > statement into /usr/local/lib/util-vserver/vserver.functions > > > > (disableInterfaces() is the func you'd probably be most interested in) > > > > to see what 'ip' commands are issued, e.g.: > > > > > > Thanks for the tip... I get > > > /sbin/ip addr del 172.16.4.170/32 broadcast + label eth0:ast dev eth0 > > > > > > Which looks right, and works fine from commandline. > > > > > > Looking further, after bringing down the vserver > > > > > > ip addr show > > > > > > Still shows all the apropriate ip's configured, however the interfaces > > > aren't up (they don't show up if I do ifconfig). So it's not deleting > > > all the addresses, just bringing down the interfaces. > > > > > > > I've got the same problem, with 2.6.8.1-vs1.92 and 2.6.9-rc3-bk3-vs1.93-rc2. > > It brings down all interfaces except lo. > > I've tried it with util-vserver 0.30.193 and util-vserver 0.30.195. > > I've added debug output to _processSingleInterface, > > _addInterfaceCmd and disableInterface. > > > > If I issue > > #ip addr del 192.168.1.2/24 broadcast + label dummy0:distcc dev dummy0 > > the interfaces are still up afterwards, but this code in > > disableInterface is not reached at all. I don't get any debug > > output from disableInterface, but all interfaces are down after > > the command "reboot -d -f -i" in the vserver, before ip addr del. > > > > If I remove the S90reboot command in rc6.d the interfaces stay up, so > > I guess there is a kernel bug, because a vserver should not be able to > > shutdown the hosts network interfaces. > > > > ############################################################## > > Just for completeness > > ############################################################## > > > > My config is the following: > > /etc/vservers# find distcc -xtype f -print -exec cat \{\} \; > > distcc/apps/pkgmgmt/internal > > distcc/interfaces/0/ip > > 192.168.1.2 > > distcc/interfaces/0/prefix > > 24 > > distcc/interfaces/0/name > > distcc > > distcc/interfaces/0/dev > > dummy0 > > distcc/uts/nodename > > distcc > > distcc/name > > distcc > > distcc/run > > 3 > > distcc/fstab > > 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 > > distcc/context > > 3 > > > > > > vserver distcc stop ; shutdown -r +2 > > _processSingleInterface(/etc/vservers/distcc/interfaces/0) > > _addInterfaceCmd(IP_ADDR 192.168.1.2/24 broadcast + label dummy0:distcc dev > > dummy0) > > _addInterfaceCmd(IP_LINK dummy0 up) > > Sending all processes the TERM signal...done. > > Sending all processes the KILL signal...done. > > Saving random seed...done. > > Unmounting remote and non-toplevel virtual filesystems...done. > > Deconfiguring network interfaces...done. > > Deactivating swap...done. > > Unmounting local filesystems...umount: /dev/hdv1: not found > > umount: /: not mounted > > done. > > mount: / not mounted already, or bad option > > Rebooting.. > > <-- All network links down --> > > hmm, please refresh my memory, what capabilities has > this vserver? because most of the executed actions > I see here should fail, but instead they seem to > succeed? > > check with 'grep Cap /proc/self/status' inside the > vserver > > TIA, > Herbert
Yes, Bjoern Steinbrink answered this a few minutes ago. modprobe capabilities A very strange debian default. I'll file a bug report. -- lg, Chris _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver