Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

> Well, if glibc (rather than NSCD) is opening the file with a shared
> mapping, that might explain the problem unmounting /var.  Really, the
> problem is caused by having file-rc keep a long-running bash open, and
> bash needing to talk to nscd.

No file-rc, and no long running (bash or other) processes. Here's
process list just before /etc/init.d/umountfs runs the umount command,
with only kernel daemons removed (they're not interesting, and too
many of them):

UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 12:42 ?        00:00:00 init [6]       
root      1119     1  0 12:47 ?        00:00:00 /bin/sh /etc/init.d/rc 6
root      1421  1119  0 12:47 ?        00:00:00 /bin/sh /etc/rc6.d/S40umountfs 
stop
root      1424  1421  0 12:47 ?        00:00:00 ps -ef

As you can see, we have just init, bash that has just spawned
/etc/init.d/rc (from initscripts), and rc has reached S40umountfs in
runlevel 6.

The real question would be, how in the hell rc managed to have
/var/db/nscd/passwd mapped, when nscd has exited long ago. Even bigger
mistery happens when I disable persistent cache, than rc somehow
"inherits" file descriptor (or was it also file mapping?) to a deleted
file in /var/run?!

rc        1119 root  mem       REG    8,9  217016   228931 /var/db/nscd/passwd

Thanks for your help!
-- 
Zlatko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to