Bug#461048: smbfs: This utility only unmounts cifs filesystems
On Wed, Jan 16, 2008 at 07:27:07PM -0800, Steve Langasek wrote:
...
On Wed, Jan 16, 2008 at 05:18:16PM +0100, Paolo wrote:
hm, seems the problem is in
mount: mount-2.12r
as it sees the mentioned cifs mounted volume whereas there is none
(/proc/mounts did not list it).
From your description, this sounds like a bug that was fixed in the upload
of 3.0.25b-2:
* cifs-umount-trailing-slashes.patch: canonicalize mount point names when
umount.cifs is called, to avoid unnecessarily leaving entries behind in
/etc/mtab if invoked with a trailing slash in the mount point name
sounds close indeed, though I did not use a trailing '/'.
Does it hang before or after the point that the share is unmounted? (Can be
checked from another console using cat /proc/mounts)
after. BTW, 'ps x' shows:
20192 ?D 0:00 /sbin/umount.cifs /home/user/share
Can you send strace output of this unmount attempt? After you hit CTRL-C,
attached
does /etc/mtab get updated, or does the unmount command terminate
immediately?
seems the latter: num.lines keep growing with mount/umount cycles.
Not smbfs-related, after all; should be reassigned to pkg mount - sorry
for the noise.
Disagree, I think this entirely an smbfs bug.
yep, partly agree here: turns out there's something wrong with umount.cifs
indeed, though [u]mount(8) is fooled by mtab while it should dbl-check
with a more reliable
thanks
--
paolo
GPG/PGP id:0x1D5A11A4 - 04FC 8EB9 51A1 5158 1425 BC12 EA57 3382 1D5A 11A4
- 9/11: the outrageous deception and ongoing coverup: http://911review.org -
stat64(/sbin/umount.cifs, {st_mode=S_IFREG|S_ISUID|0755, st_size=, ...})
= 0
clone(Process 20698 attached (waiting for parent)
Process 20698 resumed (parent 20697 ready)
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7d9a9e8) = 20698
[pid 20697] wait4(-1, Process 20697 suspended
unfinished ...
[pid 20698] getgid32() = 0
[pid 20698] setgid32(0) = 0
[pid 20698] getuid32() = 0
[pid 20698] setuid32(0) = 0
[pid 20698] execve(/sbin/umount.cifs, [/sbin/umount.cifs,
/home/user/share, -f], [/* 12 vars */]) = 0
[pid 20698] uname({sys=Linux, node=sari, ...}) = 0
[pid 20698] brk(0) = 0x804b000
[pid 20698] access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
[pid 20698] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f97000
[pid 20698] access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
[pid 20698] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f96000
[pid 20698] open(/etc/ld.so.cache, O_RDONLY) = 3
[pid 20698] fstat64(3, {st_mode=S_IFREG|0644, st_size=100247, ...}) = 0
[pid 20698] mmap2(NULL, 100247, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f7d000
[pid 20698] close(3)= 0
[pid 20698] access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
[pid 20698] open(/lib/tls/i686/cmov/libc.so.6, O_RDONLY) = 3
[pid 20698] read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240O\1..., 512) = 512
[pid 20698] fstat64(3, {st_mode=S_IFREG|0644, st_size=1241392, ...}) = 0
[pid 20698] mmap2(NULL, 1247388, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e4c000
[pid 20698] mmap2(0xb7f73000, 28672, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x127) = 0xb7f73000
[pid 20698] mmap2(0xb7f7a000, 10396, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f7a000
[pid 20698] close(3)= 0
[pid 20698] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7e4b000
[pid 20698] mprotect(0xb7f73000, 20480, PROT_READ) = 0
[pid 20698] set_thread_area({entry_number:-1 - 6, base_addr:0xb7e4b6c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
[pid 20698] munmap(0xb7f7d000, 100247) = 0
[pid 20698] geteuid32() = 0
[pid 20698] statfs64(/home/user/share, 84, {f_type=0xff534d42, f_bsize=1024,
f_blocks=16342484, f_bfree=7757104, f_bavail=7757104, f_files=0, f_ffree=0,
f_fsid={0, 0}, f_namelen=4096, f_frsize=1024}) = 0
[pid 20698] getuid32() = 0
[pid 20698] umount(/home/user/share, MNT_FORCE
Bug#461048: smbfs: This utility only unmounts cifs filesystems
Package: smbfs
Version: 3.0.24-6etch9
Severity: important
Seems last upgrade broke umount.cifs:
% # mount -t cifs
//linux/share on /home/user/share type cifs (rw,mand)
% # umount /home/user/share (or umount.cifs /home/user/share)
This utility only unmounts cifs filesystems
and the volume isn't unmounted.
And it's stale, so I'd need to umount+mount but seems my only option is
to reboot (can't do now, remote multi user system).
system is apt-updated Etch, except kernel which is
2.6.22.14-toi3.0rc3-dm-sa-k7.3
Not sure it's last codefix though: I tried 3.0.28 from a Slackware system
with same result. What's up then with {smb,cifs}fs?
thanks
--
paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461048: smbfs: This utility only unmounts cifs filesystems
On Wed, Jan 16, 2008 at 10:24:04AM +, Debian Bug Tracking System wrote: hm, seems the problem is in mount: mount-2.12r as it sees the mentioned cifs mounted volume whereas there is none (/proc/mounts did not list it). Still, there's something weird with umount.cifs: if I (really) mount the remote volume, the command succeeds, but then umount hangs. But Ctrl-C can abort it, then the volume *is* unmounted. So umount succeeds as well, but the utils fail to get the actual (u)mounted status. I'm usure who to blame here - umount or umount.cifs - but that breaks scripts. Bugging mount, since I see that mount/umount -ing the cifs volume keeps incrementing the corresponding line count in mtab ... Not smbfs-related, after all; should be reassigned to pkg mount - sorry for the noise. thanks -- paolo GPG/PGP id:0x1D5A11A4 - 04FC 8EB9 51A1 5158 1425 BC12 EA57 3382 1D5A 11A4 - 9/11: the outrageous deception and ongoing coverup: http://911review.org - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461048: smbfs: This utility only unmounts cifs filesystems
reassign 461048 smbfs
found 461048 3.0.24-6
thanks
On Wed, Jan 16, 2008 at 11:14:19AM +0100, Paolo wrote:
Package: smbfs
Version: 3.0.24-6etch9
Severity: important
Seems last upgrade broke umount.cifs:
% # mount -t cifs
//linux/share on /home/user/share type cifs (rw,mand)
% # umount /home/user/share (or umount.cifs /home/user/share)
This utility only unmounts cifs filesystems
and the volume isn't unmounted.
And it's stale, so I'd need to umount+mount but seems my only option is
to reboot (can't do now, remote multi user system).
system is apt-updated Etch, except kernel which is
2.6.22.14-toi3.0rc3-dm-sa-k7.3
Not sure it's last codefix though: I tried 3.0.28 from a Slackware system
with same result. What's up then with {smb,cifs}fs?
On Wed, Jan 16, 2008 at 05:18:16PM +0100, Paolo wrote:
hm, seems the problem is in
mount: mount-2.12r
as it sees the mentioned cifs mounted volume whereas there is none
(/proc/mounts did not list it).
From your description, this sounds like a bug that was fixed in the upload
of 3.0.25b-2:
* cifs-umount-trailing-slashes.patch: canonicalize mount point names when
umount.cifs is called, to avoid unnecessarily leaving entries behind in
/etc/mtab if invoked with a trailing slash in the mount point name
Still, there's something weird with umount.cifs: if I (really) mount the
remote volume, the command succeeds, but then umount hangs.
But Ctrl-C can abort it, then the volume *is* unmounted.
Does it hang before or after the point that the share is unmounted? (Can be
checked from another console using cat /proc/mounts)
Can you send strace output of this unmount attempt? After you hit CTRL-C,
does /etc/mtab get updated, or does the unmount command terminate
immediately?
So umount succeeds as well, but the utils fail to get the actual (u)mounted
status.
I'm usure who to blame here - umount or umount.cifs - but that breaks
scripts. Bugging mount, since I see that mount/umount -ing the cifs volume
keeps incrementing the corresponding line count in mtab ...
Not smbfs-related, after all; should be reassigned to pkg mount - sorry
for the noise.
Disagree, I think this entirely an smbfs bug.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
