On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak <kzak@xxxxxxxxxx> wrote: >> because >> really that is exactly what you want to do on your system. If our >> mount command will still attempt to write to /etc/mtab once its a real >> file again, maybe things will work for you as expected. > > No. systemd is not compatible with /etc/mtab To be clear, you are saying that systemd won't be updating /etc/mtab like the mount command tries to do? If so, I believe a sufficiently motivated admin would be able to figure out a way to manually update /etc/mtab from /proc/mounts if they wanted to see systemd mounted items in their site specific mtab they are trying to maintain. I don't think its impossible, I've seen(created) crazier site specific admin hacks to keep backwards compatibility on an as needed basis. Just for completely I've done some more historical searches and I'm seeing this argument between mtab and /proc/*/mounts going all the way back to 2000. And in all of the historic discussion I've seen relying on ./proc/*/mount has been the recommendation due to it being a canonical representation of what the mount points actually are at any given point in time. Ten+ years of trying to live with two slightly different ways of accounting for mountpoints, each with their own limitations is more than enough time. While the bind mount situation we have now is somewhat unfortunate in that we didn't catch it in time to be proactive about it in F15, the fact that we've been living with this divergence for ten years speaks volumes about the necessity to bite the bullet and cut over to the /proc/*/mount information in a release and triage accordingly as the breakage reports come it. Do you have a complete listing somewhere of the info thekernel does not encode into /proc/mounts that mount has traditionally encodes into /etc/mtab that existing tools might be making use of? I'm pretty sure based on everything I've read its not just bind mount info, but also perhaps user or group info concerning who has permission to mount and umount? Moving foward such a list would probably help mitigate frustration and give admins a starting point to adjusting their site specific configs. -jef -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
