Thanks for the quick responses! Please forgive the length here.
Also, noticing text/plain (good!) I am not sending HTML so I hope blanks
render correctly.
On 03/02/2016 10:21 PM, Pádraig Brady wrote:
CCing the mailing list.
Wish I had thought to do that. Oh well.
Ironically the preference for /proc/self/mountinfo was chosen
to give more accurate info within chroots (and for bind mounts).
The kernel has all the info, which is why we prefer that
dynamically generated info.
Yes, ironic.
And yes, the most visible problem is with bind mounts. (not only for
'chroot'; see sample output below)
What inaccuracies are you seeing exactly?
I do vaguely remember references to issues on some ubuntu kernels,
so perhaps there is a kernel fix to provide better info?
I should not have implied "inaccuracies". Sorry.
For the 'chroot' case it's more that I don't want to expose too much
about the host system.
Sounds like the rationale for crunching /proc/self/mountinfo was to get
accurate mount info.
The current code is a big step toward being more accurate in 'chroot'.
I run on a range of kernels, many of them older. But
/proc/self/mountinfo has been there for at least five years.
(I also use Coreutils and other packages, including a lot of non-Gnu
FOSS, on *BSD, Solaris, whatever. But am not expecting
/proc/self/mountinfo issues there soon.)
The change to use /proc/self/mountinfo was done in v8.24.
As a hack to avoid it, you could use an LD_PRELOAD wrapper to return
ENOENT for open("/proc/self/mountinfo"), along the lines of:
http://git.sv.gnu.org/cgit/coreutils.git/tree/tests/df/no-mtab-status.sh?id=v8.24
Thanks for the tip. I will try to get my head wrapped around that.
Some back story:
I've been doing virtualization since before I was doing Linux.
One of the helpful hacks in that space is to share some filesystems on
(shared) block devices.
There have been a number of failed attempts. (The distros now support
read-only root, or did. That helps.)
Lately, a shared "system disk" with an otherwise normal root and others
works best, and you bind these ...
bin, sbin, lib, lib64, opt, boot
... and replicate /etc and /var appropriately.
One could alternatively sym-link these particular directories, but bind
mount is cleaner.
Traditional output with a cleaned-up /etc/mtab and without
/proc/self/mountinfo:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/dasda1 2365444 1157156 1088128 52% /Linux-s390
/dev/dasdb 2365540 1683840 561532 75% /
udev 256704 0 256704 0% /dev
tmpfs 256704 0 256704 0% /tmp
New behavior where 'df' consults /proc/self/mountinfo:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 2365444 1157156 1088128 52% /lib
/dev/dasdb 2365540 1683840 561532 75% /
udev 256704 0 256704 0% /dev
tmpfs 256704 0 256704 0% /tmp
Obviously "/dev/root" is vestigial and "/lib" is misleading.
In both of these, /Linux-s390 is the system disk and the usual system
directories in the root are bind mounted to their counterparts under it.
With the new code, only "/lib" shows and it's not the desired master.
Here is the full /proc/mounts content:
rootfs / rootfs rw 0 0
/dev/root /Linux-s390 ext2 rw,relatime,errors=continue 0 0
/dev/dasdb / ext3
rw,relatime,errors=continue,barrier=0,data=ordered 0 0
/dev/root /lib ext2 ro,relatime,errors=continue 0 0
/dev/root /bin ext2 ro,relatime,errors=continue 0 0
/dev/root /sbin ext2 ro,relatime,errors=continue 0 0
/dev/root /usr ext2 rw,relatime,errors=continue 0 0
/dev/root /boot ext2 rw,relatime,errors=continue 0 0
/dev/root /opt ext2 ro,relatime,errors=continue 0 0
/sys /sys sysfs rw,relatime 0 0
udev /dev tmpfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
tmpfs /tmp tmpfs rw,relatime 0 0
proc /proc proc rw,relatime 0 0
(System disk and /boot are actually RW because I was servicing it. Just
being honest with a "live" snapshot.)
So in either case ('chroot' or not) the leakage of too much reality is
counter productive.
Fixing /etc/mtab is trivial. Hiding selected /proc content is layers
upon layers, something they do in Redmond.
On 03/03/2016 03:51 AM, Ruediger Meier wrote:
FYI issues with /etc/mtab were also discussed recently on util-linux
mailing list
http://www.spinics.net/lists/util-linux-ng/msg12386.html
Wow ... that brings up some painful recent memories. (Don't get me
started about subvols.)
I can't fight the distributors, but the trend of sym-link /etc/mtab to
/proc/mounts is annoying at best.
Would have been better if they checked at boot time, "is it a plain
file?", and go traditional for that case.
Easy enough to make it a sym-link at install time. Then the sysadmin can
manually alter the behavior if he needs or wants.
Rendering a proper /etc/mtab is not rocket science.