Gabor Gombas <[EMAIL PROTECTED]> writes: > 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) >
Yes, yes, yes. This is exactly what's happening and you explained it so nicely I take my hat off and bow in front of you. :) THANKS! At least we know now what we're dealing with here and I hope some of your suggestions will be accepted to resolve this intricate problem. -- Zlatko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
