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
