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]
