Re: [Vserver] Unexpected behaviour with bind mounts
On 10/7/05, Jim Wight <[EMAIL PROTECTED]> wrote: > I am seeing odd behaviour with bind mounts. For example, if I specify > > mount --bind /tmp /vservers/tkt/opt > > in pre-start, and > > umount /vservers/tkt/opt I have my --bind mounts in /etc/vservers/*/fstab like: ... /usr/distfiles/usr/distfiles autorbind 0 0 /usr/portage/usr/portage autorbind 0 0 No problems at all - mounted and umounted correctly. OS: Gentoo 2005.0 vserver: sys-kernel/vserver-sources-2.0, sys-cluster/util-vserver-0.30.208-r4 ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Unexpected behaviour with bind mounts
On Tue, Oct 11, 2005 at 02:38:20PM +0100, Jim Wight wrote: > On Mon, 2005-10-10 at 20:09 +0200, Herbert Poetzl wrote: > > On Mon, Oct 10, 2005 at 02:28:01PM +0100, Jim Wight wrote: > > > Implicit unmounts are not happening in my case. If I start and stop the > > > vserver a number of times I end up with a pile of multiple identical > > > mounts (according to df), but as I mentioned in my original message > > > there are no corresponding entries in /proc/mounts (as there are when I > > > perform the same mounts manually). The other odd thing is that df shows > > > different numbers compared with the manual mount case: it shows the > > > numbers for the filesystem that the mount point is in, rather than for > > > the mounted filesystem. > > > > hmm .. maybe you want to use the -n option to > > mount, so that mount does not write stuff to > > the mtab file? > > That has certainly got rid of the messages and odd-looking df output, > but is it a case of 'out of sight, out of mind'? The mounts do work - so > far - but is it normal to have to use -n? I don't think I've ever seen > it mentioned in all the searching I've done trying to find out how to do > things. really depends on _what_ you do and _what_ you want ... you should keep in mind that most tools (mount, df, ...) look at /etc/mtab and not the /proc/mounts ... the logic behind is simple: you want to keep /etc/mtab and /proc/mounts in sync ... this results in the following rules: - if you mount something on the host, you don't want -n - if you mount something for the guest, you definitely want -n for the host's mtab - if you mount something inside the guest, you don't want -n for the guest's mtab basically it's standard namespace behaviour, not even vserver related (i.e. you can observe the same with plain namespaces and chroot ... HTH, Herbert > Jim > ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Unexpected behaviour with bind mounts
On Mon, 2005-10-10 at 20:09 +0200, Herbert Poetzl wrote: > On Mon, Oct 10, 2005 at 02:28:01PM +0100, Jim Wight wrote: > > Implicit unmounts are not happening in my case. If I start and stop the > > vserver a number of times I end up with a pile of multiple identical > > mounts (according to df), but as I mentioned in my original message > > there are no corresponding entries in /proc/mounts (as there are when I > > perform the same mounts manually). The other odd thing is that df shows > > different numbers compared with the manual mount case: it shows the > > numbers for the filesystem that the mount point is in, rather than for > > the mounted filesystem. > > hmm .. maybe you want to use the -n option to > mount, so that mount does not write stuff to > the mtab file? That has certainly got rid of the messages and odd-looking df output, but is it a case of 'out of sight, out of mind'? The mounts do work - so far - but is it normal to have to use -n? I don't think I've ever seen it mentioned in all the searching I've done trying to find out how to do things. Jim ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Unexpected behaviour with bind mounts
On Mon, Oct 10, 2005 at 02:28:01PM +0100, Jim Wight wrote: > On Sat, 2005-10-08 at 16:22 +0200, Enrico Scholz wrote: > > [EMAIL PROTECTED] (Jim Wight) writes: > > > > umount /vservers/tkt/opt > > > > > > in post-stop (or postpost-stop), > > > > * these scripts are NOT executed within the vserver namespace so > > /vservers/tkt/opt is not mounted at this place > > > > * there is not much need for an explicit unmount; when the last process > > of the vserver/context dies, the namespace will not be referenced > > anymore and an implicit unmount happens > > Implicit unmounts are not happening in my case. If I start and stop the > vserver a number of times I end up with a pile of multiple identical > mounts (according to df), but as I mentioned in my original message > there are no corresponding entries in /proc/mounts (as there are when I > perform the same mounts manually). The other odd thing is that df shows > different numbers compared with the manual mount case: it shows the > numbers for the filesystem that the mount point is in, rather than for > the mounted filesystem. hmm .. maybe you want to use the -n option to mount, so that mount does not write stuff to the mtab file? HTH, Herbert > Jim > > > ___ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Unexpected behaviour with bind mounts
On Sat, 2005-10-08 at 16:22 +0200, Enrico Scholz wrote: > [EMAIL PROTECTED] (Jim Wight) writes: > > umount /vservers/tkt/opt > > > > in post-stop (or postpost-stop), > > * these scripts are NOT executed within the vserver namespace so > /vservers/tkt/opt is not mounted at this place > > * there is not much need for an explicit unmount; when the last process > of the vserver/context dies, the namespace will not be referenced > anymore and an implicit unmount happens Implicit unmounts are not happening in my case. If I start and stop the vserver a number of times I end up with a pile of multiple identical mounts (according to df), but as I mentioned in my original message there are no corresponding entries in /proc/mounts (as there are when I perform the same mounts manually). The other odd thing is that df shows different numbers compared with the manual mount case: it shows the numbers for the filesystem that the mount point is in, rather than for the mounted filesystem. Jim ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Unexpected behaviour with bind mounts
On Fri, 2005-10-07 at 22:00 +0200, Guenther Fuchs wrote: > Hi there, > > on Friday, October 7, 2005 at 16:12 on the list was posted: > > > Shutting down system logger: [ OK ] > > Starting killall: [ OK ] > > umount: /tmp: not mounted > > umount: /tmp: not mounted > > I got this behaviour as well when not using different names for all of > the interfaces (i.e. putting different names into each > /etc/vserver/*/intervaces/*/name file) > > Couldn't tell why and didn't check further, but I guess this maybe is > because of some context relating net mounts or so. After I named all > the (guest) interfaces individually I didn't get this error anymore. > > Strange, but was definately that way. No such luck in my case, I'm afraid. Jim ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Unexpected behaviour with bind mounts
[EMAIL PROTECTED] (Jim Wight) writes: > I am seeing odd behaviour with bind mounts. For example, if I specify > > mount --bind /tmp /vservers/tkt/opt > > in pre-start, and Be very careful when doing such stuff (resp. make sure that the vserver is trusted). Else, an attacker within the vserver can cause execution of arbitrary commands in the host... (hint: think of a symlink /vservers/tkt/opt -> /bin) > umount /vservers/tkt/opt > > in post-stop (or postpost-stop), * these scripts are NOT executed within the vserver namespace so /vservers/tkt/opt is not mounted at this place * there is not much need for an explicit unmount; when the last process of the vserver/context dies, the namespace will not be referenced anymore and an implicit unmount happens Enrico pgpXspse5qNCN.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Unexpected behaviour with bind mounts
Hi there, on Friday, October 7, 2005 at 16:12 on the list was posted: > Shutting down system logger: [ OK ] > Starting killall: [ OK ] > umount: /tmp: not mounted > umount: /tmp: not mounted I got this behaviour as well when not using different names for all of the interfaces (i.e. putting different names into each /etc/vserver/*/intervaces/*/name file) Couldn't tell why and didn't check further, but I guess this maybe is because of some context relating net mounts or so. After I named all the (guest) interfaces individually I didn't get this error anymore. Strange, but was definately that way. -- regards, Guenther Fuchs ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Unexpected behaviour with bind mounts
I am seeing odd behaviour with bind mounts. For example, if I specify mount --bind /tmp /vservers/tkt/opt in pre-start, and umount /vservers/tkt/opt in post-stop (or postpost-stop), I get this when I stop vserver tkt: Shutting down system logger: [ OK ] Starting killall: [ OK ] umount: /tmp: not mounted umount: /tmp: not mounted /tmp is not mounted when the vserver has been stopped. I don't believe I am attempting umounts from anywhere else: I have /etc/rc.d/init.d/halt linked to /bin/true, and if I comment out the umount in post-stop, /tmp/does not get unmounted. However, if I then attempt it manually I get the error message as above - as well as the unmount taking place. While the vserver is running there isn't an entry on the host for the mount in /proc/mounts - should there be? - but there is in /etc/mtab. Also, while the vserver is running, df on the host shows this: # df /tmp /vservers/tkt/opt Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda5 5124508 1563176 3561332 31% / /tmp 5242716 3033028 2209688 58% /vservers/tkt/opt Note that the numbers in the /tmp line are different from when I perform the same mount directly on the host, where df shows: Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda5 5124508 1563176 3561332 31% / /tmp 5124508 1563176 3561332 31% /vservers/tkt/opt In this case there is an entry in /proc/mounts. The numbers in the /tmp line in the first case are those for the /vservers partition. How much of the above relating to the vserver is normal, and how much abnormal? Within the vserver, the contents of /opt are those of the host's /tmp, so none of this is actually stopping me from doing anything. It just doesn't seem right. I'm using kernel 2.6.12.5 with patch-2.6.12.4-vs2.0 and util-server-0.30.208. Both the host and the vserver are based on Fedora Core 4. Jim ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
