Whose bug is this?

[Roland Mas <lolando@debian.org>]

  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)