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: always 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
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...
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.
Chunking on the shouldfix list.
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.
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.
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.
> 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.
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 -and- 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.
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.
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.
Still current for RHEL4.
Moving to FC devel; this is unlikely to change for already-released RHEL. *** This bug has been marked as a duplicate of 145892 ***