On Wed, Aug 31, 2005 at 01:36:24PM +0900, GOTO Masanori wrote: > > root 1119 1 0 12:47 ? 00:00:00 /bin/sh /etc/init.d/rc 6 [...] > > rc 1119 root mem REG 8,9 217016 228931 > > /var/db/nscd/passwd > > It's very weird behavior. Please disable nscd when your boot up time, > and then run /etc/init.d/nscd. You can see which processes have such > nscd file descriptor (fd), and you can clear process inheritance with > pstree easily. If nothing has nscd fd, we can clear rc behaves oddly.
Well, if /bin/sh is bash, then it is not weird at all, it is the same "bash vs. NSS" problem that came up several times in the past (last time quite recently on debian-devel). Previously it only happened with NSS modules that link to libraries under /usr, now it also affects nscd. What I _suspect_ is happening here: - by calling /etc/init.d/rc, bash is executed - bash unconditionally does some NSS calls during startup (getpwuid etc.); this in turn - loads all NSS modules that serve passwd maps -> if a module uses libraries from /usr, now you have a live memory mapping under /usr so you cannot unmount it during shutdown - bash (libc) connects to nscd - nscd sends a file descriptor of /var/db/nscd/passwd to bash, and bash does an mmap(2) on the received fd -> now you have a live memory mapping under /var thus you cannot unmount it during shutdown - /etc/init.d/rc eventually kills nscd but that does not help, since the bash process executing /etc/init.d/rc still has the cache file mapped (deleting the cache file also doesn't help since unlink(2) only operates on the directory and does not invalidate the memory mapping) Options you have to avoid the problem: 1. Stop using bash as /bin/sh 2. Stop using nscd 3. Convert /etc/init.d/rc to be an ELF executable instead of a shell script 4. Let /var (and /usr if you are running more exotic NSS modules) be the same filesystem as / 5. Redesign the init system so unmounting of local file systems is done _after_ /etc/init/rc has finished (and the program that does the unmounting must not be a shell script) Gabor -- --------------------------------------------------------- MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences --------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]