Whose bug is this?
Hi all,
I'd like your opinion on a problem I am encountering. I suppose
there's a bug somewhere, but I'm not sure it's in any one particular
package or if it just lies in the combination of several packages.
A bit of context: I maintain the sourceforge package, this package
provides CVS and/or shell accounts to users through an LDAP directory.
No problem until now? Good.
Now let's reboot, for some reason. Not a crash, note, a clean
reboot and all. When entering runlevel 6 (or 0), the S40umountfs
script is executed (/etc/init.d/umountfs). This script basically does
an 'umount -a -r'. And it barfs on /usr: tells me "Device or resource
busy", then "Not mounted", then "Illegal seek". And obviously, I have
to wait during fsck at the following boot. I hope I'm entitled to
consider this a bug. Now, whose bug is this?
I did a bit of investigation (with lsof), and came to the fact that
apparently the rc script uses /usr/lib/libldap.so.2.0.9 and
/usr/lib/liblber.so.2.0.9, both of which are on /usr. Trial and error
told me that the configuration at fault was the "passwd: files ldap"
line in /etc/nsswitch.conf (remove the ldap part and all is fine, the
"group" and "shadow" lines have no influence). Random poking around
led me to the conclusion that replacing the /bin/sh shebang in both
/etc/init.d/rc and /etc/init.d/umountfs with a /bin/ash one fixed the
symptom too.
So? Whose fault is this? Probably not mine, because I can't find
any reason I shouldn't have LDAP users. Is it bash's fault (/bin/sh
is a symlink to bash here), for keeping its libraries open? Is it
sysvinit's fault, for using bash instead of ash? Is it libldap2's
fault, for putting libs in /usr/lib instead of /lib?
Thanks for any help,
Roland.
--
Roland Mas
The best definition of an immortal is someone who hasn't died yet.
-- in Ye Gods! (Tom Holt)
Reply to: