Yes, I'm giving systemd a try; so it makes sense to synchronize state of insserv and systemd. I tried upgrading packages such as insserv and systemd; I would need to check the logs if they were already on experimental before the problem occurred. Today I only updated to unstable; but I have upgraded packages to experimental before.
Maybe insserv is the better place to prevent this from happening than in the shell script. The shell script was just easier for me to break the cycle. There may also be an issue involved with cyclic dependencies in insserv; but I was unable to pinpoint them. insserv output was completely useless in trying to figure out where the cycle might be, and the additional tools (visualizing with dotty etc.) also did not yield anything corresponding to the error messages. In fact, some of the related services were missing from the dotty plot; I can only assume that insserv gets some data from systemd, but the visualization tools do not. On Sat, Mar 1, 2014 at 10:04 PM, Petter Reinholdtsen <p...@hungry.com> wrote: > Control: reassign -1 insserv > Control: found -1 1.16.0-3 > > [Erich Schubert] >> insserv: Note: sysvinit service dbus is shadowed by systemd dbus.service, >> Forwarding request to '/bin/systemctl --quiet --no-reload enable >> dbus.service'. >> Synchronizing state for dbus.service with sysvinit using update-rc.d... >> Executing /usr/sbin/update-rc.d dbus defaults > > This tell me that you are not using the insserv version in unstable, > but the one in experimental with systemd integration support. Are you > using systemd, or only have it installed? > >> Please add a safeguard against cyclic invocation of update-rc.d. Thanks. > > I suspect this should be fixed in insserv, not in update-rc.d. > Reassigning there. > > -- > 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
