Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Umount a filesystem fails, even if no proccesses are accessing it

On Fri, Jan 04, 2008 at 06:55:52PM -0500, David Holland wrote:
> On Fri, Jan 04, 2008 at 10:58:54PM +0100, Bernd Ernesti wrote:
>  > > >  umount: /home/source: Device busy
>  > 
>  > [..]
>  > 
>  > > there are still handles open on /home/source.  "fstat -f /home/source"
>  > > may reveal which processes which have them open.
>  > 
>  > I used fstat, but I can't remeber now if I used it with -f, where that flag
>  > shouldn't make a difference since -f only narrows down the search to one
>  > file system.
>  > 
>  > fstat didn't show any open file handles for /home/source
> Unfortunately, fstat shows open files, and if the problem is a
> refcounting bug on vnodes rather than open files, it is stale vnodes
> that will be hanging around, and the results of fstat will be null or
> even misleading.
> Also unfortunately, refcounting bugs are notoriously hard to track
> down.

I could try it because it is kind of reproduceable, but it takes time because
it happens for one of the 700 packages which I had build.
But I would need to know what I should do when it happens.

I don't know if this is related, but there were two kernel messages before I 
to unmount the filesyste, something which happend during the pkgsrc build:

set{u,g}id pid 7405 (netstat) was invoked by uid 1234 ppid 4328 (shlibsign) 
with fd 0 closed
set{u,g}id pid 8477 (netstat) was invoked by uid 1234 ppid 7368 (shlibsign) 
with fd 0 closed

Btw, I was trying to get a crash dump in this situation, but then this
panic happend:

db> sync
syncing disks... 83 81 76 68 62 57 47 43 37 34 30 done
unmounting file systems...uvm_fault(0xc0848760, 0, 1) -> 0xe
kernel: supervisor trap page fault, code=0
Stopped in pid 10719.1 (bash) at        netbsd:pmap_page_remove+0x72:   movl    
db> bt
pmap_page_remove(c2a7f7d8,1,1,d91ff23e,1c4526b6) at netbsd:pmap_page_remove+0x72

genfs_do_putpages(cc2190bc,0,0,0,0) at netbsd:genfs_do_putpages+0xb2b
genfs_putpages(ce865548,1,0,c066e880,cc2190bc) at netbsd:genfs_putpages+0x3d
VOP_PUTPAGES(cc2190bc,0,0,0,0) at netbsd:VOP_PUTPAGES+0x40
vinvalbuf(cc2190bc,1,ffffffff,d801a0a0,0) at netbsd:vinvalbuf+0x47
vclean(0,0,0,cc2195e0,c3228000) at netbsd:vclean+0x160
vgonel(cc2190bc,d801a0a0,ce865634,c0426146,cc1f1140) at netbsd:vgonel+0x53
vflush(c3228000,0,3,0,0) at netbsd:vflush+0x9c
ffs_flushfiles(c3228000,2,d801a0a0,5000,c322801c) at netbsd:ffs_flushfiles+0x46
ffs_unmount(c3228000,80000,d000f300,0,ce8656e0) at netbsd:ffs_unmount+0x49
dounmount(c3228000,80000,d801a0a0,0,ce865710) at netbsd:dounmount+0xa5
vfs_unmountall(d801a0a0,0,0,d,c0814260) at netbsd:vfs_unmountall+0x85
vfs_shutdown(c083fec0,ce865754,c01cb0b4,c01cd6dc,c0494f56) at 
cpu_reboot(100,0,ce865814,c01cb938,c0813905) at netbsd:cpu_reboot+0x13d
db_sync_cmd(c0813905,0,c0813900,ce865784,a) at netbsd:db_sync_cmd+0x1f
db_command(c074cac4,0,c09153de,c048b4f3,0) at netbsd:db_command+0xc8
db_command_loop(c048b4f3,29df,1,d2f7da49,800) at netbsd:db_command_loop+0xd2
db_trap(6,0,58,c03c241c,5) at netbsd:db_trap+0xfc
kdb_trap(6,0,ce8659b0,1,e) at netbsd:kdb_trap+0xde
trap() at netbsd:trap+0x248
--- trap (number 6) ---
pvtree_SPLAY(c2a7f810,ce865a40,c0845a38,c1923d10,ce865acc) at 
pmap_remove_pv(c2a7f80c,0,810f000,7ffff467,5) at netbsd:pmap_remove_pv+0x29
pmap_do_remove(0,bbaf5000,bbbc7000,3,0) at netbsd:pmap_do_remove+0x2ce
uvm_unmap_remove(d004418c,0,bfc00000,ce865b5c,0) at 
uvmspace_free(d004418c,0,ce865bd8,5,3) at netbsd:uvmspace_free+0xd1
exit1(d801a0a0,0,0,d801a0a0,c07d302c) at netbsd:exit1+0x1f8
sys_exit(d801a0a0,ce865c30,ce865c58,bbbd6004,bbbd6000) at netbsd:sys_exit+0x4d
syscall(ce865c78,b3,ab,1f,1f) at netbsd:syscall+0x124

Another sync succeeded but I got no crash dump from savecore.


Home | Main Index | Thread Index | Old Index