Bug 140809 - initial fstab should contain info for mqueue filesystem
initial fstab should contain info for mqueue filesystem
Status: CLOSED DUPLICATE of bug 145892
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-11-24 20:32 EST by Ulrich Drepper
Modified: 2014-03-16 22:50 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-21 17:25:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ulrich Drepper 2004-11-24 20:32:54 EST
Description of problem:
I actually don't know where the initial /etc/fstab is created.  I assume
anaconda; if this is wrong, please reassign.

The problem is that the mqueue filesystem is not mounted.  This makes it
impossible to determine which message queues have been created and more
importantly, it makes it cumbersome to remove existing message queues (i.e., we
ship no tool to do this, one would have to write a new one).

Therefore I suggest adding such an entry to /etc/fstab when it is created.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Compile this code
#include <fcntl.h>
#include <mqueue.h>
int main (void) {
struct mq_attr a;
return mq_open("/aaa", O_CREAT|O_RDWR,0600, 0);

2.run it
3.try to remove the message queue /aaa
Actual results:
need to write program using mq_unlink

Expected results:
rm /dev/mqueue/aaa

Additional info:
I don't know whether there is a standard for the name of the directory where the
filesystem is mounted.  I doubt it.  Therefore add

none                    /dev/mqueue              mqueue   nodev,noexec    0 0
Comment 1 Jeremy Katz 2004-11-25 00:09:44 EST
Most of these we've been doing mounts for in rc.sysinit as opposed to explicit
lines in /etc/fstab.  Of course, there are the more general questions of what
this is used for, wtf it's an all new filesystem, that there _needs_ to be a
standardized location to mount it among others...
Comment 2 Ulrich Drepper 2004-11-25 00:25:53 EST
I think I explained fairly well why this filesystem needs to be mounted.  There
is no way for a sysadmin to see what message queues are created and take up
resources.  And there is no tool to remove them.  With or without a standard
mounting point, we need this mount.  It's something new in RHEL4 since RHEL3 had
no message queues which is why this is not available so far.

And as for mounting in rc.sysinit.  I don't think it's adequate, we should have
the entry in /etc/fstab just as there is an entry for /dev/shm.
Comment 3 Jay Turner 2004-11-25 09:13:08 EST
Chunking on the shouldfix list.
Comment 4 Bill Nottingham 2004-11-28 15:38:22 EST
Jay: new *features* at this stage on the shouldfix list? *giggle*.

If it's going to be in /etc/fstab, it needs to be created in anaconda, or similar.
Comment 5 Jeremy Katz 2004-11-28 16:58:52 EST
I'm just not clear on why this is implemented as yet another bizarro filesystem
that then has to be mounted by everyone causing more slow-down to the bootup
process, confusion on things when it's not mounted (ie -- in what situations do
I now need this for chroots), etc.

Hence, why I don't think that "just add it to /etc/fstab" is a good enough answer.

Plus, I'd like some sort of real consensus other than us just making something
up on if we have to mount something on _where_ it gets mounted.  And /dev is
ugly due to dev now being tmpfs for udev.
Comment 6 Jay Turner 2004-11-29 02:39:03 EST
Uni reported it, so it got some points for that, plus it *felt* like one of
those things that if we were going to do it, then it needed to be done in GA and
not something which was introduced at an update.  So, if the resolution is,
"Nope, we're not doing this" that's good enough in my opionion.  Remember, one
of the key tenets of these lists is to get to a resolution, not necessarily fix
every issue.
Comment 7 Ulrich Drepper 2004-12-06 20:18:52 EST
> I'm just not clear on why this is implemented as yet another bizarro filesystem
> that then has to be mounted by everyone

If this would not have to be done with a filesystem, we would yet another
"bizarro" tools like ipcs.  Using a filesystem is *much* more desirable.

And back to the issue.  Imagine a system without ipcs.  This is exactly where we
are now wrt to POSIX mqs.  The sysadmin needs to be able to have insight.  We
need to have the filesystem mounted.
Comment 12 Bill Nottingham 2005-02-15 00:00:58 EST
OK, so the options are thus:

1) Add support for /etc/fstab.d. Package a file that goes there.
2) Add a hotplug helper that automatically mounts the filesystem
   when the filesystem is registered with the kernel
3) Add the filesystem to /etc/fstab. This requires:
   a) modifying anaconda
   b) add a %post to some package to do the fstab modifications on upgrade
4) Randomly mount the filesystem in rc.sysinit (like /proc, /sys)

Note that 2), while relatively clean, and useful for filesystems in
general, may not work at all. 1) obviously requires work to both
mount and to libc for *mntent.

So, in any case, 1), 2), and 3b) require changes to a package.
Logically, this goes in the package that introduces the functionality.

Assigning to kernel for now; I suppose it could be libc as well.
Comment 13 Ulrich Drepper 2005-02-15 00:14:05 EST
1) is really no option IMO.  This is unnecessary, non-standard, and
has the potential for limitless confusion.  What happens if there are
multiple entries for the same mount point?  What about programs
parsing /etc/fstab directly?  What about statically linked code using
old libc code?

3) is the correct solution but refused because it is work.  This
shouldn't be reason enough.

I don't know enough hotplug to judge 2).  And how is it supposed to
work?  Message queues are no module.  Support is always compiled in. 
Has it been checked whether there is any hook in the code which calls
into hotplug?

4) is probably the least intrusive possibility.  I'd be OK with it
although it is plainly inconsistent since /dev/shm is handled in fstab.
Comment 14 Bill Nottingham 2005-02-15 00:23:01 EST
3) is certainly doable. It's just that initscripts really isn't the
place for the fstab-modifying %post.

One minor note is that 3/4 it also requires a udev change to make any
subdirectory on startup  if it's under /dev, but that's doable.
Comment 15 Bastien Nocera 2005-05-06 05:01:15 EDT
Still current for RHEL4.
Comment 16 Bill Nottingham 2005-09-21 17:25:48 EDT
Moving to FC devel; this is unlikely to change for already-released RHEL.

*** This bug has been marked as a duplicate of 145892 ***

Note You need to log in before you can comment on or make changes to this bug.