umount do actually its job but does not update mtab. eject and all X environments that use eject inherit this problem. Small test: voleg]$ grep cdrom /etc/fstab /dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0 voleg]$ mount /mnt/cdrom voleg]$ mount ..... ..... /dev/cdrom on /mnt/cdrom type iso9660 (ro,nosuid,nodev,user=voleg) voleg]$ umount /mnt/cdrom cannot open /etc/mtab.tmp (Invalid argument) - mtab not updated voleg]$ mount ..... ..... /dev/cdrom on /mnt/cdrom type iso9660 (ro,nosuid,nodev,user=voleg) voleg]$ mount /mnt/cdrom voleg]$ mount ..... ..... /dev/cdrom on /mnt/cdrom type iso9660 (ro,nosuid,nodev,user=voleg) /dev/cdrom on /mnt/cdrom type iso9660 (ro,nosuid,nodev,user=voleg) voleg]$ umount /mnt/cdrom umount: it seems /mnt/cdrom is mounted multiple times
This is happening on my box as well.
I can't reproduce the problem here, with mount-2.11n-9 installed. The heart of the problem is the failure to create mtab.tmp, which I do not see. Any weird things in your environment that would cause this?
This is what i have done: AFter a fresh install (everything option) I boot into kde. Second, I insert a cd (this happens to be the skipjack SRPMS disk) and 'mount /mnt/cdrom' . Below is my sequence of commands, at the end you can see /dev/cdrom mounted twice. Hope this helps, if you need more info, feel free to contact me DanC (dan_cunningham) [daniel@dansquake daniel]$ df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda3 16690232 3467084 12375320 22% / /dev/sda1 31079 5981 23494 21% /boot none 257192 0 257192 0% /dev/shm [daniel@dansquake daniel]$ mount /mnt/cdrom [daniel@dansquake daniel]$ df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda3 16690232 3467084 12375320 22% / /dev/sda1 31079 5981 23494 21% /boot none 257192 0 257192 0% /dev/shm /dev/cdrom 654002 654002 0 100% /mnt/cdrom [daniel@dansquake daniel]$ umount /mnt/cdrom cannot open /etc/mtab.tmp (Invalid argument) - mtab not updated [daniel@dansquake daniel]$ df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda3 16690232 3467084 12375320 22% / /dev/sda1 31079 5981 23494 21% /boot none 257192 0 257192 0% /dev/shm /dev/cdrom 16690232 3467084 12375320 22% /mnt/cdrom [daniel@dansquake daniel]$ umount /dev/cdrom umount: /dev/cdrom: not mounted [daniel@dansquake daniel]$ df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda3 16690232 3467084 12375320 22% / /dev/sda1 31079 5981 23494 21% /boot none 257192 0 257192 0% /dev/shm [daniel@dansquake daniel]$ eject [daniel@dansquake daniel]$ umount /mnt/cdrom umount: /mnt/cdrom is not mounted (according to mtab) [daniel@dansquake daniel]$ mount /mnt/cdrom [daniel@dansquake daniel]$ eject cannot open /etc/mtab.tmp (Invalid argument) - mtab not updated [daniel@dansquake daniel]$ mount /dev/cdrom [daniel@dansquake daniel]$ cd /mnt/cdrom [daniel@dansquake cdrom]$ ls beta_eula.txt README-Accessibility RPM-GPG-KEY-beta TRANS.TBL README RPM-GPG-KEY SRPMS [daniel@dansquake cdrom]$ cd [daniel@dansquake daniel]$ umount /dev/cdrom umount: it seems /dev/cdrom is mounted multiple times [daniel@dansquake daniel]$ df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda3 16690232 3467084 12375320 22% / /dev/sda1 31079 5981 23494 21% /boot none 257192 0 257192 0% /dev/shm /dev/cdrom 654002 654002 0 100% /mnt/cdrom /dev/cdrom 654002 654002 0 100% /mnt/cdrom [daniel@dansquake daniel]$
By the way, you can also see I'm doing this from a unpriviledged account (non root), might be inportant?
Tried to downgrade to mount 2.11g (from rh72), the problem persistant. So it is not a problem with mount package. Still digging.
Created attachment 50444 [details] Tracefile by "strace -f -F -i -o mtr -s 256 -u voleg umount /mnt/cdrom"
According tracefile an /etc/mtab.tmp attempted to create with 0666 mode. Actually created file has permissions: $ ll /etc/mtab.tmp -rw-r--r-- 1 root voleg 0 Mar 26 13:53 /etc/mtab.tmp and still in /etc directory. Permissions for /etc: $ ll -d /etc drwxr-xr-x 53 root root 8192 Mar 26 13:54 /etc
The mode passed to open() is combined with the user's umask, explaining the difference. The curious thing is that the open() is succeeding but somehow the fopen() is seen as failing. Until it is something that I can reproduce on my system, all I can do is try to help you guys track down the problem.
Yes, but my umask (nether thught about it) is 002 that should cause in -rw-rw-r-- permissions , and not as above. The file /etc/mtab.tmp created with group voleg, may be umount want to write it using uid voleg through group permissions. In this case group permissions does not allow to write to this file. To differ with Daniel installation, that claimed ti be clean install, my installation was upgrade from RH7.2 . What common to that installation? I cleaned environment with unset and unalias commands, but still having this behaviour. Do you think, "rpm -qa" would help ?
# ldd /bin/umount libc.so.6 => /lib/i686/libc.so.6 (0x40025000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) # ll /lib/i686/libc.so.6 lrwxrwxrwx 1 root root 13 Mar 24 17:33 /lib/i686/libc.so.6 -> libc-2.2.5.so # ll /lib/i686/libc-2.2.5.so -rwxr-xr-x 1 root root 1400136 Mar 14 22:34 /lib/i686/libc-2.2.5.so A long time ago libc has more than 5M. This size is very strange. # rpm -qf /lib/i686/libc-2.2.5.so glibc-2.2.5-27 # rpm -V glibc .......T c /etc/rpc
Can't reproduce it on another clean-install system here either, although the behaviour has been spotted. Very strange.
Because I tried to downgrade to stable mount package from rh7.2 and still have the same problem, a problem is not in mount. Mount is linked with libc, wich comes with glibc-2.2.5-27 rpm. As pointed above abnormal size of this libc may show a problem. A bug number 62280 was opened to glibc guys. I suppose to get an updated glibc to verify this, and close the subject.
It's not likely this is a glibc problem (and, seeing as how jakub gave a correct response to the other bug, you know that now :) Most likely it's some odd thing in the environment. Others around here have seen the problem on rare occasions, but have not been able to reproduce it. Most likely this will wind up staying unfixed until someone here can reproduce the problem reliably.
This is a trivial bug in mount in the error checking code. I'm attaching a patch. After applying this patch, the problem seems to be gone. My patch should be applied to fstab.c in util-linux-2.11n/mount. It is constructed such that you can apply it with -p1 from the util-linux-2.11n build directory.
Created attachment 51564 [details] patch to correct problem
Any reason that this bug is still open? I see the patch has been applied in -11 and that it is included in beta2.
Yea, patch applied, thanks.