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]
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 URL: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]
