Bug#324900: nscd: umount /var fails (unclean shutdowns)
Daniel Jacobowitz <drow@false.org> 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
Reply to: