Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
Control: -1 found insserv/1.14.0-2 Control: -1 retitle depending on a script that depends on $all (including by not having LSB headers) creates loop We've encountered this problem many times with locally-written init scripts without LSB headers, since they get an implicit dependency on $all, which will create a loop if there is any other header with an implicit dependency on $all. But the best solution is to just add LSB headers. This problem already existed in exactly this form in squeeze. Setting the found version accordingly. I think the severity for this bug is wrong, although I was hesitant to change it when the maintainers are involved in the discussion. But I think it's important at worst. This behavior is unchanged since stable and really represents a bug in the local init script, which doesn't have the headers to be properly fit into the dependency tree. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
On Thu, Dec 13, 2012 at 09:15:12AM +0100, Adrin wrote: This is the find output: # find /etc -name '*vpnagentd_init*' /etc/rc5.d/K25vpnagentd_init /etc/rc5.d/S85vpnagentd_init /etc/init.d/vpnagentd_init /etc/rc4.d/K25vpnagentd_init /etc/rc4.d/S85vpnagentd_init /etc/rc2.d/K25vpnagentd_init /etc/rc2.d/S85vpnagentd_init /etc/rc3.d/K25vpnagentd_init /etc/rc3.d/S85vpnagentd_init OK, I've solved the problem. If you adjust your symlinks like this: (sid)root@hufflepuff:/# find /etc -name '*vpnagentd_init' | sort | xargs ls -l -rwxr-xr-x 1 root root 1153 Dec 4 08:46 /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 24 Dec 14 22:52 /etc/rc0.d/K01vpnagentd_init - ../init.d/vpnagentd_init lrwxrwxrwx 1 root root 24 Dec 14 22:52 /etc/rc1.d/K01vpnagentd_init - ../init.d/vpnagentd_init lrwxrwxrwx 1 root root 26 Dec 4 08:46 /etc/rc2.d/S21vpnagentd_init - /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 26 Dec 4 08:46 /etc/rc3.d/S21vpnagentd_init - /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 26 Dec 4 08:46 /etc/rc4.d/S21vpnagentd_init - /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 26 Dec 4 08:46 /etc/rc5.d/S21vpnagentd_init - /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 24 Dec 14 22:52 /etc/rc6.d/K01vpnagentd_init - ../init.d/vpnagentd_init And then run insserv: (sid)root@hufflepuff:/# insserv insserv: warning: script 'K01vpnagentd_init' missing LSB tags and overrides insserv: warning: script 'vpnagentd_init' missing LSB tags and overrides It will then adjust the links and all will be well. Not entirely sure why this shows two warnings though. I think the cryptic errors you were getting were a result of S85 being higher than the biggest runlevel S21 in used by insserv. This then makes it get placed after $all and hence the dependency loop. That's my theory anyway--I haven't looked at the code yet. The stop number is adjusted to be first, and has also been removed from runlevels 2-5 and added to runlevels 0, 1 and 6. However, it does look like there's room for improvement here. If we haven't got an LSB header, why does the number get used at all? Isn't its presence in this runlevel sufficient? If so, we could just ignore the number and have insserv assign it one appropriately. Likewise for stop links. I hope this makes some degree of sense. I'm still not entirely sure about how the internals work here. I didn't notice issues like this testing upgrades, possibly due to there always being a script at S99. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
On Thu, Dec 13, 2012 at 09:15:12AM +0100, Adrin wrote: This is the find output: # find /etc -name '*vpnagentd_init*' /etc/rc5.d/K25vpnagentd_init /etc/rc5.d/S85vpnagentd_init /etc/init.d/vpnagentd_init /etc/rc4.d/K25vpnagentd_init /etc/rc4.d/S85vpnagentd_init /etc/rc2.d/K25vpnagentd_init /etc/rc2.d/S85vpnagentd_init /etc/rc3.d/K25vpnagentd_init /etc/rc3.d/S85vpnagentd_init And the attached is what you asked for. Thanks. With this, I can reproduce the issue in a chroot environment. I don't see this with just the script alone, so I can only assume this is a result of the symlinks you have in the rc.d directories. If I delete all the rc?.d/*vpnagentd_init links, insserv runs without error. Also, if I create a Snnvpnagentd_init link in rcS.d, it also works without error. But, if I create an S link in rc[2345].d, the error is then triggered. So this looks like the implicit $all dependency is only working in the context of rcS. Small note: You don't need the K links in rc[2345].d; restricting them to rc[016] is fine. This doesn't have any effect on the problem in question. One thing I'm not entirely clear on is how $all interacts with runlevels. Is there a $all at the end of every runlevel, or is this restricted to rcS? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
[Roger Leigh] One thing I'm not entirely clear on is how $all interacts with runlevels. Is there a $all at the end of every runlevel, or is this restricted to rcS? $all do not work the way you think. :) I'm told by the insserv author that all init.d scripts are sorted into a global dependency based ordering across all runlevels. This is used to decide the order number for each script. When this is done, all scripts depending on $all is assigned the highest order number plus one, to ensure they all end up at the end of the boot sequence. Because of this, I recommend to avoid $all if at all possible. It do not work the way most people (myself included) expect, and can lead to incorrect boot ordering if a script depend on a script which in turn depend on $all. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
On 13.12.2012 21:19, Petter Reinholdtsen wrote: Because of this, I recommend to avoid $all if at all possible. It do not work the way most people (myself included) expect, and can lead to incorrect boot ordering if a script depend on a script which in turn depend on $all. Seems we do have quite a few packages using $all (see attached file). Seing that $all can lead to such unwanted behaviour, maybe it would be worth investigating if all those sysv init scripts actually need $all (and file bugs accordingly). Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? boinc-client/init.d/boinc-client:# Required-Start:$all bootchart/init.d/bootchart:# Required-Start:$remote_fs $all bootlogd/init.d/stop-bootlogd:# Required-Start:$local_fs $all bootlogd/init.d/stop-bootlogd-single:# Required-Start:$local_fs $all cardstories/init.d/cardstories:# Required-Start:$all cardstories/init.d/cardstories:# Required-Stop: $all collectl/init.d/collectl:# Required-Start:$all collectl/init.d/collectl:# Required-Stop: $all debian-edu-install/init.d/xdebian-edu-firstboot:# Required-Start:$remote_fs $all dhcp-probe/init.d/dhcp-probe:# Required-Start:$local_fs $remote_fs $syslog $network $all dtc-xen-firewall/init.d/dtc-xen-firewall:# Required-Start:$remote_fs $all dtc-xen/init.d/dtc-xen:# Required-Start:$all flashybrid/init.d/flashybrid:# Required-Start:$all gunicorn/init.d/gunicorn:# Required-Start: $all gunicorn/init.d/gunicorn:# Required-Stop: $all initscripts/init.d/rc.local:# Required-Start:$all initscripts/init.d/rmnologin:# Required-Start:$remote_fs $all initscripts/init.d/single:# Required-Start:$local_fs $all killprocs laptop-mode-tools/init.d/laptop-mode:# Should-Start: $all mediatomb-daemon/init.d/mediatomb:# Should-Start: $all mediatomb-daemon/init.d/mediatomb:# Should-Stop: $all minidlna/init.d/minidlna:# Should-Start: $all minidlna/init.d/minidlna:# Should-Stop: $all minissdpd/init.d/minissdpd:# Required-Start:$remote_fs $all mon/init.d/mon:# Required-Start:$remote_fs $all monit/init.d/monit:# Should-Start: $all monit/init.d/monit:# Should-Stop: $all ngetty/init.d/ngetty:# Required-Start:$all ngetty/init.d/ngetty:# Required-Stop: $all noflushd/init.d/noflushd:# Required-Start: $syslog $remote_fs $all oar-node/init.d/oar-node:# Required-Start: $all oar-node/init.d/oar-node:# Required-Stop:$all oar-server/init.d/oar-server:# Required-Start:$network $local_fs $remote_fs $all plymouth/init.d/plymouth:# Required-Start: udev $remote_fs $all portsentry/init.d/portsentry:# Required-Start:$remote_fs $syslog $all readahead-fedora/init.d/stop-readahead-fedora:# Required-Start:$all reniced/init.d/reniced:# Required-Start:$all reniced/init.d/reniced:# Required-Stop: $all shinken-arbiter/init.d/shinken-arbiter:# Required-Start:$all shinken-arbiter/init.d/shinken-arbiter:# Required-Stop: $all shinken-broker/init.d/shinken-broker:# Required-Start:$all shinken-broker/init.d/shinken-broker:# Required-Stop: $all shinken-poller/init.d/shinken-poller:# Required-Start:$all shinken-poller/init.d/shinken-poller:# Required-Stop: $all shinken-reactionner/init.d/shinken-reactionner:# Required-Start:$all shinken-reactionner/init.d/shinken-reactionner:# Required-Stop: $all shinken-receiver/init.d/shinken-receiver:# Required-Start:$all shinken-receiver/init.d/shinken-receiver:# Required-Stop: $all shinken-scheduler/init.d/shinken-scheduler:# Required-Start:$all shinken-scheduler/init.d/shinken-scheduler:# Required-Stop: $all torque-scheduler/init.d/torque-scheduler:# Required-Start:$all torque-scheduler/init.d/torque-scheduler:# Required-Stop: $all torque-scheduler/init.d/torque-scheduler:# Should-Start: $all torque-scheduler/init.d/torque-scheduler:# Should-Stop: $all watchdog/init.d/watchdog:# Required-Start:$all watchdog/init.d/watchdog:# Required-Stop: $all watchdog/init.d/wd_keepalive:# X-Start-Before:$all xymon-client/init.d/hobbit-client:# Should-Start: $all xymon/init.d/hobbit:# Should-Start: $all signature.asc Description: OpenPGP digital signature
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
[Michael Biebl] Seems we do have quite a few packages using $all (see attached file). Yes. But it only become a problem if there are any scripts that depend on any of the scripts that depend on $all. :) Seing that $all can lead to such unwanted behaviour, maybe it would be worth investigating if all those sysv init scripts actually need $all (and file bugs accordingly). Yeah. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
On 12/12/12 09:32, adrin wrote: I can not upgrade gdm3 as follows. This does not necessarily look like gdm3's fault to me. dpkg: error processing gdm3 (--configure): subprocess installed post-installation script returned error exit status 1 There does seem to be a bug of some sort here: gdm3.postinst shouldn't exit unsuccessfully without a message. If you edit /var/lib/dpkg/gdm3.postinst and add a line set -x just below the set -e, then retry the installation, it might become clearer what went wrong? insserv: warning: script 'K25vpnagentd_init' missing LSB tags and overrides insserv: warning: script 'vpnagentd_init' missing LSB tags and overrides insserv: Starting vpnagentd_init depends on laptop-mode and therefore on system facility `$all' which can not be true! Where does this /etc/init.d/vpnagentd_init script come from? I think this is what's causing the problem. It looks as though that script needs LSB tags (http://wiki.debian.org/LSBInitScripts) in order for the installation of any package with an init script to succeed. As a result, laptop-mode-tools, gdm3 and exim4-base (which each contain an init script) all fail to install: insserv: Starting vpnagentd_init depends on laptop-mode and therefore on system facility `$all' which can not be true! ... insserv: There is a loop at service laptop-mode if started insserv: There is a loop at service vpnagentd_init if started ... insserv: There is a loop between service laptop-mode and mountkernfs if started insserv: loop involving service mountkernfs at depth 1 insserv: Starting vpnagentd_init depends on laptop-mode and therefore on system facility `$all' which can not be true! ... insserv: exiting now without changing boot order! update-rc.d: error: insserv rejected the script header dpkg: error processing exim4-base (--configure): subprocess installed post-installation script returned error exit status 1 Regards, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
reassign 695751 insserv thanks Hi adrin, On 12.12.2012 12:14, Simon McVittie wrote: On 12/12/12 09:32, adrin wrote: insserv: warning: script 'K25vpnagentd_init' missing LSB tags and overrides insserv: warning: script 'vpnagentd_init' missing LSB tags and overrides insserv: Starting vpnagentd_init depends on laptop-mode and therefore on system facility `$all' which can not be true! Where does this /etc/init.d/vpnagentd_init script come from? I think this is what's causing the problem. It looks as though that script needs LSB tags (http://wiki.debian.org/LSBInitScripts) in order for the installation of any package with an init script to succeed. As a result, laptop-mode-tools, gdm3 and exim4-base (which each contain an init script) all fail to install: insserv: Starting vpnagentd_init depends on laptop-mode and therefore on system facility `$all' which can not be true! ... insserv: There is a loop at service laptop-mode if started insserv: There is a loop at service vpnagentd_init if started ... insserv: There is a loop between service laptop-mode and mountkernfs if started insserv: loop involving service mountkernfs at depth 1 insserv: Starting vpnagentd_init depends on laptop-mode and therefore on system facility `$all' which can not be true! ... insserv: exiting now without changing boot order! update-rc.d: error: insserv rejected the script header dpkg: error processing exim4-base (--configure): subprocess installed post-installation script returned error exit status 1 I've re-assigned the bug report to insserv and so their maintainers can have a look at what is causing the problem. To diagnose the problem we need more information: 1/ the output of /usr/share/insserv/make-testsuite 2/ the contents of /etc/init.d/: tar czf etc-initd.tar.gz /etc/init.d/ Please attach this information when you reply. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
[Michael Biebl] insserv: warning: script 'K25vpnagentd_init' missing LSB tags and overrides insserv: warning: script 'vpnagentd_init' missing LSB tags and overrides insserv: Starting vpnagentd_init depends on laptop-mode and therefore on system facility `$all' which can not be true! Where does this /etc/init.d/vpnagentd_init script come from? I think this is what's causing the problem. I agree. The boot sequence system seem to refuse to continue to avoid leaving the boot system in an unknown and possibly broken state. The fix is to add correct LSB headers in /etc/init.d/vpnagentd_init. To diagnose the problem we need more information: 1/ the output of /usr/share/insserv/make-testsuite 2/ the contents of /etc/init.d/: tar czf etc-initd.tar.gz /etc/init.d/ The output from make-testsuite is most likely enough to reproduce the problem. It repliactes the LSB info in /etc/init.d/. There is also a problem with insserv here, as it should provide scripts without LSB headers with a sensible default. This no longer seem to happen. No idea why. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
On Wed, Dec 12, 2012 at 01:41:26PM +0100, Adrin wrote: Hi, Thanks for the fast follow up. Two files are attached and this is the more comprehensive report by adding set -x: Thanks for the files. The trigger for the problem is vpnagentd_init, which lacks LSB headers. But there's nothing strictly wrong with this in and of itself. And there's nothing explicitly tying it to laptop-mode. /etc/init.d/laptop-mode contains: # Should-Start: $all # Required-Start:$remote_fs Could you change this to # Should-Start: # Required-Start:$remote_fs $all and then retry the apt-get install -f command? I think the reason this is causing problems is that Should-Start: $all isn't strict enough, which leads to the loop in the dependency graph; making it required should fix things (I hope). Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
On Wed, Dec 12, 2012 at 01:41:26PM +0100, Adrin wrote: Hi, Thanks for the fast follow up. Two files are attached and this is the more comprehensive report by adding set -x: I've tried to reproduce the failure on a clean wheezy install this evening using the /etc/init.d directory you provided. I'm afraid that I can't reproduce the failure at all. I just get a warning, and insserv completes without error. Possibly this is also dependent upon the links in the rcn.d directories. What does find /etc -name '*vpnagentd_init*' show? Would it be possible to have the entire content of your initscripts e.g. tar cfvz /tmp/initfiles.tar.gz /etc/rc?.d /etc/insserv* /etc/init.d so I can try to reproduce with the exact setup you have? Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
