Bug#541349: insserv sets the start up link for autofs to S01autofs
Or should nis say it provides nis as well as what it currently says it provides or instead of? I think using LDAP as a Network Information Service (see RFC2307) may be relevant here. I don't know whether that's possible on Linux at the moment but I would guess that if it is (or ever will be) then it may not involve ypbind. So perhaps that's pointing towards /etc/init.d/nis saying it provides nis and that /etc/init.d/autofs depends on nis if it's installed. And then ldap as a Network Information Service could say it provides nis. Just a thought. -- Andy, BlueArc Engineering -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541349: insserv sets the start up link for autofs to S01autofs
[Andy Chittenden] I think using LDAP as a Network Information Service (see RFC2307) may be relevant here. I don't know whether that's possible on Linux at the moment but I would guess that if it is (or ever will be) then it may not involve ypbind. So perhaps that's pointing towards /etc/init.d/nis saying it provides nis and that /etc/init.d/autofs depends on nis if it's installed. And then ldap as a Network Information Service could say it provides nis. Just a thought. For LDAP, there are two options. libnss-ldap do not start a daemon, and will work as soon as the network is up. libnss-ldapd on the other hand do need a daemon, started by the nslcd script. I believe the service used by autofs is really NSS and not NIS, and thus any nss plugin might be used to provide autofs maps. I am not aware of anyone using anything else than NIS and LDAP, and thus proposed a patch to handle those cases. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541349: insserv sets the start up link for autofs to S01autofs
Having applied your patch to autofs and reenabling insserv, I had to reinstall
portmap to get its links in /etc/rc*d so that when nis started, the portmapper
was enabled.
Once I'd done that, autofs is still starting before nis:
ws-andyc-debian64:~# ls /etc/rc*d/*{nis,autofs}
/etc/rc0.d/K01autofs /etc/rc2.d/S15nis /etc/rc4.d/S15nis
/etc/rc1.d/K01autofs /etc/rc3.d/S02autofs /etc/rc5.d/S02autofs
/etc/rc1.d/K01nis /etc/rc3.d/S15nis /etc/rc5.d/S15nis
/etc/rc2.d/S02autofs /etc/rc4.d/S02autofs /etc/rc6.d/K01autofs
It's not clear to me from man insserv whether that's OK or not. It could be
that Should-Start: is taken care of when autofs is started. Having thought
about that, that would mean that whatever nis is dependent on would also need
starting before nis is started and that would lead to working out dependencies
on the fly: that seems counter to the purpose of creating the links in the
respective directories in the first place so that cannot be right. So there
must be something else awry.
I did try reinstalling nis to see whether that would help (it didn't).
--
Andy, BlueArc Engineering
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541349: insserv sets the start up link for autofs to S01autofs
[Andy Chittenden] Once I'd done that, autofs is still starting before nis: I had a closer look at the nis script, and it do not provide nis (which I expected it to do), but ypbind, ypserv, ypxfrd and yppasswdd. The init.d dependency relations are to the strings provided by other scripts, so this mean autofs need to have a relation on one of the facilities provided by the nis script. I suspect ypbind is the correct one. Does it help to use this one instead in init.d/autofs: # Should-Start:ypbind In my opinion, the nis script should be changed to provide 'nis' (in addition to or instead of) the existing provides. I tested this on my test laptop, and with this header in place, autofs is started after nis. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541349: insserv sets the start up link for autofs to S01autofs
having had a look at /etc/init.d/nis, I see it says:
# Provides: ypbind ypserv ypxfrd yppasswdd
So, I thought perhaps autofs shouldn't say nis in Should-Start but should say
ypbind. Having done that and rerun insserv, the start files look ok:
ws-andyc-debian64:~# ls /etc/rc*d/*{nis,autofs}
/etc/rc0.d/K01autofs /etc/rc2.d/S16autofs /etc/rc4.d/S16autofs
/etc/rc1.d/K01autofs /etc/rc3.d/S15nis /etc/rc5.d/S15nis
/etc/rc1.d/K01nis /etc/rc3.d/S16autofs /etc/rc5.d/S16autofs
/etc/rc2.d/S15nis /etc/rc4.d/S15nis /etc/rc6.d/K01autofs
So, is that the right thing to do? Or should nis say it provides nis as well as
what it currently says it provides or instead of?
--
Andy, BlueArc Engineering
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541349: insserv sets the start up link for autofs to S01autofs
[Andy Chittenden] having had a look at /etc/init.d/nis, I see it says: # Provides: ypbind ypserv ypxfrd yppasswdd So, I thought perhaps autofs shouldn't say nis in Should-Start but should say ypbind. Having done that and rerun insserv, the start files look ok: Good. Thank you for verifying the fix. :) When the dependencies are correct, the boot sequence is correct too. :) As you have seen, incorrect dependencies can be a fatal problem. :) So, is that the right thing to do? Yes, it is the right thing to do at the moment, and if it is done, nis should keep providing ypbind until all init.d scripts currently depending on ypbind have changed their dependency to something else. Or should nis say it provides nis as well as what it currently says it provides or instead of? I would say that this really depend on the plans for the nis script. I've asked for the nis script to be split into several parts, one starting ypbind and another starting ypserv, ypxfrd and yppasswdd. If such split was ever done, the new scripts should provide the individual services. On the other hand, it is less surprising if all scripts provide their own name (minus the .sh ending). At least I would have avoided initially proposing the wrong dependency in this case if the nis script provided the nis service. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541349: insserv sets the start up link for autofs to S01autofs
Package: insserv Version: 1.12.0-10 Severity: critical Justification: breaks unrelated software autofs should start after nis but autofs is being started with level 01 whereas nis is being started with level 17: # ls /etc/rc*d/*nis /etc/rc1.d/K01nis@ /etc/rc3.d/S17nis@ /etc/rc5.d/S17nis@ /etc/rc2.d/S17nis@ /etc/rc4.d/S17nis@ # ls /etc/rc*d/*autofs /etc/rc0.d/K01autofs@ /etc/rc3.d/S01autofs@ /etc/rc6.d/K01autofs@ /etc/rc1.d/K01autofs@ /etc/rc4.d/S01autofs@ /etc/rc2.d/S01autofs@ /etc/rc5.d/S01autofs@ This makes autofs unusable. It looks like a lot of startup scripts are also being run at level 01: /etc/rc1.d/S01killprocs@ /etc/rc4.d/S01binfmt-support@ /etc/rc2.d/S01autofs@ /etc/rc4.d/S01edac@ /etc/rc2.d/S01binfmt-support@ /etc/rc4.d/S01fancontrol@ /etc/rc2.d/S01edac@/etc/rc4.d/S01mercury-base@ /etc/rc2.d/S01fancontrol@ /etc/rc4.d/S01nvidia-glx@ /etc/rc2.d/S01mercury-base@/etc/rc4.d/S01nvidia-kernel@ /etc/rc2.d/S01nvidia-glx@ /etc/rc4.d/S01openvpn@ /etc/rc2.d/S01nvidia-kernel@ /etc/rc4.d/S01snmpd@ /etc/rc2.d/S01openvpn@ /etc/rc4.d/S01sysklogd@ /etc/rc2.d/S01snmpd@ /etc/rc4.d/S01syslog-ng@ /etc/rc2.d/S01sysklogd@/etc/rc4.d/S01uml-utilities@ /etc/rc2.d/S01syslog-ng@ /etc/rc4.d/S01winbind@ /etc/rc2.d/S01uml-utilities@ /etc/rc5.d/S01autofs@ /etc/rc2.d/S01winbind@ /etc/rc5.d/S01binfmt-support@ /etc/rc3.d/S01autofs@ /etc/rc5.d/S01edac@ /etc/rc3.d/S01binfmt-support@ /etc/rc5.d/S01fancontrol@ /etc/rc3.d/S01edac@/etc/rc5.d/S01mercury-base@ /etc/rc3.d/S01fancontrol@ /etc/rc5.d/S01nvidia-glx@ /etc/rc3.d/S01mercury-base@/etc/rc5.d/S01nvidia-kernel@ /etc/rc3.d/S01nvidia-glx@ /etc/rc5.d/S01openvpn@ /etc/rc3.d/S01nvidia-kernel@ /etc/rc5.d/S01snmpd@ /etc/rc3.d/S01openvpn@ /etc/rc5.d/S01sysklogd@ /etc/rc3.d/S01snmpd@ /etc/rc5.d/S01syslog-ng@ /etc/rc3.d/S01sysklogd@/etc/rc5.d/S01uml-utilities@ /etc/rc3.d/S01syslog-ng@ /etc/rc5.d/S01winbind@ /etc/rc3.d/S01uml-utilities@ /etc/rcS.d/S01hostname.sh@ /etc/rc3.d/S01winbind@ /etc/rcS.d/S01mountkernfs.sh@ /etc/rc4.d/S01autofs@ so I expect some of them to be broken too (on other systems without insserv installed, there's very few level 01 scripts). On a different system, I managed to dpkg-reconfigure insserv and disabled it. That resets the autofs level to 19. However, it left the system needing its filesystems checking manually on next boot. Having done that, the system is now unable to boot: I'm guessing that the scripts' order hasn't been restored properly. -- System Information: Debian Release: squeeze/sid APT prefers transitional APT policy: (500, 'transitional'), (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages insserv depends on: ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy ii initscripts 2.87dsf-2 scripts for initializing and shutt ii libc6 2.9-23 GNU C Library: Shared libraries ii sysv-rc 2.87dsf-2 System-V-like runlevel change mech ii sysvinit-utils2.87dsf-2 System-V-like utilities insserv recommends no packages. Versions of packages insserv suggests: pn bootchart none (no description available) -- debconf information: insserv/enable: true -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541349: insserv sets the start up link for autofs to S01autofs
reassign 541349 autofs retitle 541349 autofs: Incorrect init.d dependency info make script start to early found 541349 4.1.4+debian-2.1 user initscripts-ng-de...@lists.alioth.debian.org usertag 541349 + incorrect-dependency thanks [Andrew Chittenden] autofs should start after nis but autofs is being started with level 01 whereas nis is being started with level 17: The dependency information provided by the autofs init.d script currently look like this in version 4.1.4+debian-2.1: ### BEGIN INIT INFO # Provides:autofs # Required-Start: $local_fs # Required-Stop: $local_fs # Default-Start: 2 3 4 5 # Default-Stop:0 1 6 # Short-Description: automount daemon # Description: daemon to mount (possibly remote) filesystems # automatically upon entering the mountpoint ### END INIT INFO If autofs need to start after nis, it should list nis in its Required-Start header. Thank you for bringing this to our attention. The bug need to be fixed in autofs. Debian unstable switched to dependency based boot sequencing recently, and the packages failing to specify correct dependency information in their init.d scripts need to be fixed. As far as I know, most scripts in the 850 packages with init.d scripts have correct dependency information already. Reassigning this bug to autofs. If you are aware of other scripts with incorrect dependency information (I see you mention several, but it is not obvious to me that these have wrong dependency information), please report them as bugs too. I am aware of openvpn (#539764) already being reported. I'll have a look at binfmt-support, edac, fancontrol, mercury-base, nvidia-glx, nvidia-kernel, snmpd, sysklogd, syslog-ng, uml-utilities and winbind to see if these are buggy too. I suspect most of these are just fine starting without a running syslog collector. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#541349: insserv sets the start up link for autofs to S01autofs
Processing commands for cont...@bugs.debian.org: reassign 541349 autofs Bug #541349 [insserv] insserv sets the start up link for autofs to S01autofs Bug reassigned from package 'insserv' to 'autofs'. Bug No longer marked as found in versions insserv/1.12.0-10. retitle 541349 autofs: Incorrect init.d dependency info make script start to early Bug #541349 [autofs] insserv sets the start up link for autofs to S01autofs Changed Bug title to 'autofs: Incorrect init.d dependency info make script start to early' from 'insserv sets the start up link for autofs to S01autofs' found 541349 4.1.4+debian-2.1 Bug #541349 [autofs] autofs: Incorrect init.d dependency info make script start to early There is no source info for the package 'autofs' at version '4.1.4+debian-2.1' with architecture '' Unable to make a source version for version '4.1.4+debian-2.1' Bug Marked as found in versions 4.1.4+debian-2.1. user initscripts-ng-de...@lists.alioth.debian.org Setting user to initscripts-ng-de...@lists.alioth.debian.org (was p...@hungry.com). usertag 541349 + incorrect-dependency Bug#541349: autofs: Incorrect init.d dependency info make script start to early There were no usertags set. Usertags are now: incorrect-dependency. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541349: insserv sets the start up link for autofs to S01autofs
[Petter Reinholdtsen] I'll have a look at binfmt-support, edac, fancontrol, mercury-base, nvidia-glx, nvidia-kernel, snmpd, sysklogd, syslog-ng, uml-utilities and winbind to see if these are buggy too. I suspect most of these are just fine starting without a running syslog collector. For the record, I had a look, and the dependencies of binfmt-support, sysklogd, syslog-ng, nvidia-glx, nvidia-kernel and uml-utilities seem to be correct. Found broken dependies in lm-sensors (not fancontrol, but another script - #541363), snmpd (#541366) and winbind (#541367). Was unable to find any package with the mercury-base init.d script, so I was unable to verify its dependencies. Again, thank you for bringing these to my attention. :) If you want to check out the dependency graph for the init.d scripts on your machine, you can use /usr/share/insserv/check-initd-order -g to generate a graph file to pass to dotty in the graphviz package to view the graph. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
