SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Is it necessary to bug the user about the mtab file being "deprecated"? Isn't that just a choice?
When using automount (autofs) I found there were differences in behaviour between /proc/self/mounts and /etc/mtab: when it came to unmounting, filesystems appeared to be removed from /proc/self/mounts at the start of the unmounting process, but were removed from /etc/mtab when the unmount completed. For slow devices like usb-sticks which might take a minute or so to flush buffers this could be important. For this reason, (and for the fact that /etc/mtab doesn't show extraneous information) I prefer to keep the file.
Is it necessary to bug the user about the mtab file being "deprecated"? Isn't that just a choice?
When using automount (autofs) I found there were differences in behaviour between /proc/self/mounts and /etc/mtab: when it came to unmounting, filesystems appeared to be removed from /proc/self/mounts at the start of the unmounting process, but were removed from /etc/mtab when the unmount completed. For slow devices like usb-sticks which might take a minute or so to flush buffers this could be important. For this reason, (and for the fact that /etc/mtab doesn't show extraneous information) I prefer to keep the file.
Hi GazL,
I searched for this, and came across several links:
These seem to suggest that since linux>2.6.26, all information that is present in /etc/mtab is also provided in /proc/self/mounts, and also some software (like systemd) seems to depend on it, so I guess it was done as a path of least resistance (there seem to be some advantages as well for switching).
Thanks for the reply. Unless I find a good reason not too, I'll continue to use a file. Shouldn't be too difficult to take the warning out of the openrc code if it comes to it. I was just curious why they even care if someone is using a file rather than /proc/mounts. I'm waiting on a new hard drive, so I can't really play with this stuff until that arrives as I'm short on free partitions at present.
One thing that could also be done externally for using OpenRC stand-alone is incorporating a small check execution during the packaging stage of SlackBuilds installing init scripts into /etc/rc.d. I started adding these into my own SlackBuilds like ConsoleKit2:
Code:
if [ -d /etc/rc.d ]; then
mkdir -p $PKG/etc/rc.d
cp -a $CWD/rc.<bootscript name>
fi
to avoid installing unnecessary files if the intended directory of installation is not present.
Personally, I removed all the Slackware standard init rc scripts and setup OpenRC to run stand-alone.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
I was just curious why they even care if someone is using a file rather than /proc/mounts. I'm waiting on a new hard drive, so I can't really play with this stuff until that arrives as I'm short on free partitions at present. 
