nss-ldapd init script sequence number
Hi, I maintain nss-ldapd, a replacement for nss_ldap which uses a local daemon (nslcd) to proxy name lookup requests (passwd/group/hosts/etc) to an LDAP server. I have received a bug report (#475626) that I would welcome some input on. The problem is that a lot of daemons are started at sequence 20 (/etc/rc2.d/S20...) an may want to do name lookups (e.g. exim is mentioned in the bugreport). This means that nslcd should probably be started before sequence 20. However, slapd is started at sequence 19 and it would be best to start nslcd after slapd. Currently nslcd is started at sequence 20. The problem with starting nslcd before slapd is that slapd does name lookups during startup which slow down slapd startup by about 5 seconds (because slapd is not ready to handle lookups yet) and leaves nslcd in a state where it believes the LDAP server is unreachable and will only retry after some timeout has expired. This could in turn cause failed lookups for processes that do name lookups just after slapd has been started. So, what would the best solution for this problem? - request slapd to be started at sequence 18 and start nslcd at sequence 19 when this has changed (haven't extensively checked if that would cause problems for slapd) - add some magic to nslcd to do more retries during startup and handle this case especially - something else?? This also brings up the problem with what to do with existing installations. If I understand correctly changing the parameter to update-rc.d will not change any existing symlinks so any changes that are made now will only affect existing installations. Feedback is very much appreciated (also other feedback related to nss-ldapd). Thanks. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Bug#475626: nss-ldapd init script sequence number
[Arthur de Jong] > So, what would the best solution for this problem? > > - request slapd to be started at sequence 18 and start nslcd at > sequence 19 when this has changed (haven't extensively checked if that > would cause problems for slapd) > - add some magic to nslcd to do more retries during startup and handle > this case especially > - something else?? This is exactly the kind of problems the dependency based boot sequencing is supposed to solve. See http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot> for information about this effort. Almost all packages with init.d scripts in Lenny now contain dependency information, and it is definitely ready for more general testing. You would then get away with adding a reverse dependency on slapd, and the proper sequence would be generated automatically. Anyway, while we wait for Debian to switch to dependency based boot sequencing, I believe the best option for you is to get slapd moved at the start and end. (note that when it moves earlier in the boot, it should also move later in the shutdown. If it should move to 18 or an earlier number, depend on which other packages depend on it. Perhaps you can use the LSB-style dependency headers to track down packages that need to start before slapd, in case any of those need to be moved too. > This also brings up the problem with what to do with existing > installations. If I understand correctly changing the parameter to > update-rc.d will not change any existing symlinks so any changes > that are made now will only affect existing installations. This is correct. If you want to change the sequence number, the only option provided by the update-rc.d interface is to remove all start/stop symlinks and insert it again with new sequence numbers. I suspect we should extend the update-rc.d interface to make this easier too, unless we just switch to dependency based boot sequencing and thus can forget about these sequence numbers. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#475626: nss-ldapd init script sequence number
On Mon, 2008-04-28 at 16:38 +0200, Petter Reinholdtsen wrote: > This is exactly the kind of problems the dependency based boot > sequencing is supposed to solve. [...] I have added: Should-Start: slapd to fix the problem that nslcd should be started after slapd. However to solve the problem that nslcd should be started before mail servers I would like to add: Provides: $named at least exim and postfix have a Required-Start for this) but the description on http://wiki.debian.org/LSBInitScripts suggests that such a provides should be specified in a different place. Where should that be? > Anyway, while we wait for Debian to switch to dependency based boot > sequencing, I believe the best option for you is to get slapd moved at > the start and end. I have filed bug #478674 for this. The end sequence is already very high (80) so I don't think there is a reason to make this even higher. The dependencies of slapd are either started at runlevel S ($remote_fs and $network) or at sequence 10 ($syslog). > > This also brings up the problem with what to do with existing > > installations. If I understand correctly changing the parameter to > > update-rc.d will not change any existing symlinks so any changes > > that are made now will only affect existing installations. > > This is correct. If you want to change the sequence number, the only > option provided by the update-rc.d interface is to remove all > start/stop symlinks and insert it again with new sequence numbers. This would however change local customisations that administrators may have made to their init script order. Something like this could do it though in postinst: [ -l /etc/rc2.d/S20nslcd ] && mv /etc/rc2.d/S20nslcd /etc/rc2.d/S19nslcd [ -l /etc/rc3.d/S20nslcd ] && mv /etc/rc3.d/S20nslcd /etc/rc3.d/S19nslcd [ -l /etc/rc4.d/S20nslcd ] && mv /etc/rc4.d/S20nslcd /etc/rc4.d/S19nslcd [ -l /etc/rc5.d/S20nslcd ] && mv /etc/rc5.d/S20nslcd /etc/rc5.d/S19nslcd [ -l /etc/rc0.d/K20nslcd ] && mv /etc/rc0.d/K20nslcd /etc/rc0.d/K21nslcd [ -l /etc/rc1.d/K20nslcd ] && mv /etc/rc1.d/K20nslcd /etc/rc1.d/K21nslcd [ -l /etc/rc6.d/K20nslcd ] && mv /etc/rc6.d/K20nslcd /etc/rc6.d/K21nslcd However this would work around update-rc.d and be a policy violation: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3 I suspect not much packages do this when changing sequence number. e.g. I have an etch system which has been upgraded a lot of times that starts nscd at sequence 19 but my sid system that has been installed about a year ago starts it at 20. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Bug#475626: nss-ldapd init script sequence number
[Arthur de Jong] > However to solve the problem that nslcd should be started before mail > servers I would like to add: > Provides: $named > at least exim and postfix have a Required-Start for this) but the > description on http://wiki.debian.org/LSBInitScripts suggests that > such a provides should be specified in a different place. Where > should that be? I suspect you instead should use X-Start-Before: exim4 postfix to make sure nslcd start before these. > This would however change local customisations that administrators > may have made to their init script order. Yes, that is correct. This is why I propose to extend the update-rc.d interface to allow changes without having to throw away local customisations. > Something like this could do it though in postinst: > > [ -l /etc/rc2.d/S20nslcd ] && > mv /etc/rc2.d/S20nslcd /etc/rc2.d/S19nslcd > [ -l /etc/rc3.d/S20nslcd ] && This do not work with file-rc. You have to use the interface provided by update-rc.d to work with both sysv-rc and file-rc. This only allow complete removal and insertion. :/ > I suspect not much packages do this when changing sequence number. e.g. > I have an etch system which has been upgraded a lot of times that starts > nscd at sequence 19 but my sid system that has been installed about a > year ago starts it at 20. Yeah. :/ Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
