[systemd-devel] How to get rid of this ordering cycle?
Hi again, Thank you all, removing dbus from the prerequisites did the trick. No more ordering cycles and mintsystem still runs fine. It turned out that mintsystem didn't even require dbus to work. Must be a copy-paste mistake (from some other init script) by the author... As for the adjustments themselves, I personally don't like these modifications too, but I'm really not in the position to decide whether to keep them in Mint or not. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to get rid of this ordering cycle?
Hi, I have Debian Testing running with some additional packages from Linux Mint which are installed for testing purposes. One of them is mintsystem, which causes an ordering cycle during the boot: авг 14 13:51:06 jessica systemd[1]: Found ordering cycle on basic.target/start авг 14 13:51:06 jessica systemd[1]: Found dependency on sysinit.target/start авг 14 13:51:06 jessica systemd[1]: Found dependency on mintsystem.service/start авг 14 13:51:06 jessica systemd[1]: Found dependency on dbus.service/start авг 14 13:51:06 jessica systemd[1]: Found dependency on basic.target/start авг 14 13:51:06 jessica systemd[1]: Breaking ordering cycle by deleting job mintsystem.service/start авг 14 13:51:06 jessica systemd[1]: Job mintsystem.service/start deleted to break ordering cycle starting with basic.target/start The init script in mintsystem package is /etc/init.d/mintsystem. Here's its contents: #! /bin/sh ### BEGIN INIT INFO # Provides: mintsystem # Required-Start:$local_fs $syslog $remote_fs dbus # Required-Stop: $local_fs $syslog $remote_fs # Default-Start: S # Default-Stop: ### END INIT INFO /usr/lib/linuxmint/mintSystem/mint-adjust.py I'd like to know: what can I change in this script to get rid of the ordering cycle? Thanks in advance. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
On Thu, 14.08.14 16:27, Vlad Orlov (mon...@inbox.ru) wrote: Hi, I have Debian Testing running with some additional packages from Linux Mint which are installed for testing purposes. One of them is mintsystem, which causes an ordering cycle during the boot: авг 14 13:51:06 jessica systemd[1]: Found ordering cycle on basic.target/start авг 14 13:51:06 jessica systemd[1]: Found dependency on sysinit.target/start авг 14 13:51:06 jessica systemd[1]: Found dependency on mintsystem.service/start авг 14 13:51:06 jessica systemd[1]: Found dependency on dbus.service/start авг 14 13:51:06 jessica systemd[1]: Found dependency on basic.target/start авг 14 13:51:06 jessica systemd[1]: Breaking ordering cycle by deleting job mintsystem.service/start авг 14 13:51:06 jessica systemd[1]: Job mintsystem.service/start deleted to break ordering cycle starting with basic.target/start The init script in mintsystem package is /etc/init.d/mintsystem. Here's its contents: #! /bin/sh ### BEGIN INIT INFO # Provides: mintsystem # Required-Start:$local_fs $syslog $remote_fs dbus # Required-Stop: $local_fs $syslog $remote_fs # Default-Start: S # Default-Stop: ### END INIT INFO /usr/lib/linuxmint/mintSystem/mint-adjust.py I'd like to know: what can I change in this script to get rid of the ordering cycle? This must be a really old systemd version? So the problem here is that you want this to be started in the S runlevel, i.e. during early boot. But you also want this to run after dbus. dbus however is only started in late boot. You have to make a decision here: run the thing in early boot (and hence not in S), or run it after dbus. Both you cannot do, that's not possible... That said, we removed support for sysv init scripts as part of early-boot a long time ago. Your distro's systemd must be really old or somebody must have patched that it added that back in. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
On 14/08/14 13:27, Vlad Orlov wrote: ### BEGIN INIT INFO # Provides: mintsystem # Required-Start:$local_fs $syslog $remote_fs dbus # Required-Stop: $local_fs $syslog $remote_fs # Default-Start: S # Default-Stop: ### END INIT INFO As Lennart said, this is Debian-(and-its-derivatives)-specific: upstream systemd does not support sysvinit services during early boot, i.e. rcS. In Debian, support for sysvinit scripts in rcS was patched back in to avoid breaking existing software, because it's unlikely that all of the packages listed in http://codesearch.debian.net/search?q=Default-Start%3A\s*S will get a native systemd unit any time soon. Most of them probably doesn't actually need to run in rcS - nvi? seriously? - but if fixing them all was on the critical path for adopting systemd, we'd probably still be using sysvinit for years to come. Default-Start: S means basic-target.target depends on mintsystem.service, which depends on dbus.service, which does not have DefaultDependencies=no, so it implicitly depends on sysinit.target, so you lose. Or to put it in sysvinit terms, this is still incorrect: a service started in rcS should not depend on dbus, which is started in rc2. (Perhaps dbus should use DefaultDependencies=no - I think all it actually needs are syslog.socket and /usr - but it has traditionally been run in rc2.) I'd like to know: what can I change in this script to get rid of the ordering cycle? You can start it later, in rc2 (so it can start after dbus.service); or you can make it not depend on dbus if it doesn't actually need dbus-daemon; or you can modify dbus.service to use DefaultDependencies=no and declare its dependencies explicitly; or you can delete it. If mint-adjust.py is https://github.com/linuxmint/mintsystem/blob/master/usr/lib/linuxmint/mintSystem/mint-adjust.py then, ugh, this is the sort of thing that should not be done (and Debian Policy specifically forbids it). Linux Mint should ship a patched version of Debian's base-files package instead, like Ubuntu, SteamOS and other Debian derivatives do: that's the correct place to declare your OS to be a fork of Debian. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
On 14/08/14 14:31, Simon McVittie wrote: Default-Start: S means basic-target.target depends on mintsystem.service, which depends on dbus.service, which does not have DefaultDependencies=no, so it implicitly depends on sysinit.target, so you lose. Sorry, that's not quite right. Default-Start: S translates into making sysinit.target depend on mintsystem.service, and mintsystem.service depends on dbus.service, which implicitly depends on basic.target as a result of default dependencies, and basic.target depends on sysinit.target. So, again, a cycle. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
On Thu, 14.08.14 14:31, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: In Debian, support for sysvinit scripts in rcS was patched back in to avoid breaking existing software, because it's unlikely that all of the packages listed in http://codesearch.debian.net/search?q=Default-Start%3A\s*S will get a native systemd unit any time soon. Most of them probably doesn't actually need to run in rcS - nvi? seriously? - but if fixing them all was on the critical path for adopting systemd, we'd probably still be using sysvinit for years to come. I have the suspicion that this creates as many problems as it solves... That's why we removed support for that, especially since there's no realy standard about this anyway... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
On Thu, Aug 14, 2014 at 02:31:00PM +0100, Simon McVittie wrote: On 14/08/14 13:27, Vlad Orlov wrote: ### BEGIN INIT INFO # Provides: mintsystem # Required-Start:$local_fs $syslog $remote_fs dbus # Required-Stop: $local_fs $syslog $remote_fs # Default-Start: S # Default-Stop: ### END INIT INFO As Lennart said, this is Debian-(and-its-derivatives)-specific: upstream systemd does not support sysvinit services during early boot, i.e. rcS. In Debian, support for sysvinit scripts in rcS was patched back in to avoid breaking existing software, because it's unlikely that all of the packages listed in http://codesearch.debian.net/search?q=Default-Start%3A\s*S will get a native systemd unit any time soon. Most of them probably doesn't actually need to run in rcS - nvi? seriously? - but if fixing them all was on the critical path for adopting systemd, we'd probably still be using sysvinit for years to come. Actually, most of them probably don't need to run at all: util-linux: hwclock.sh - not necessary with systemd systemd: Copy rules generated while the root was ro - argh, installing a sysv script as part of systemd? udev: Start udevd, populate /dev and load drivers - ?? procps: Configure kernel parameters at boottime - not necessary with systemd, probably downright harmful sysvinit:- n/a kmod: Load the modules listed in /etc/modules - not necessary with systemd console-setup: - not necessary with systemd, probably will cause a mess by duplicating functionality xorg:- I doubt that this has to run in early boot insserv: - n/a, seems to be some tests fuse:- Not sure what this does, but it proably should be started on demand only and then there's lvm2: ifupdown: So there's two scripts to convert, and a bunch to disable. Those that should be disabled are either already disabled with systemd, or will have to be for correctness anyway. And that leaves two scripts to take care of. At least for lvm2, converting it to properly support systemd seems to be a prerequisite for proper shutdown, and is something that it worth doing anyway. For some of those scripts, support in systemd might be inadequate. But fixing/enhancing systemd is imho a much better approach than adding workarounds in obsolete init scripts. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
On 14/08/14 16:04, Zbigniew Jędrzejewski-Szmek wrote: Actually, most of them probably don't need to run at all: Many of the ones you quoted indeed don't make sense with systemd and are either explicitly masked by a symlink to /dev/null, or have a corresponding native systemd service that overrides them - notably, everything in systemd, sysvinit, util-linux and procps - but you might have missed the next page link at the bottom? There are about 4 pages of results at the moment. That search is among source packages, not binaries, so it'll match anything that ships a rcS script, whether we would actually execute that script under systemd or not. (The ones in the systemd source package are for udev on a non-systemd init system, FWIW.) At some point a mass-bug-filing on packages that ship an rcS script without a corresponding systemd service would make sense, yes. Hopefully many of them could be dealt with by masking the sysvinit script and shipping a tmpfiles.d fragment. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
On Thu, 14.08.14 17:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: systemd: Copy rules generated while the root was ro Hmm, wut? What's that supposed to be? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
On 14/08/14 16:29, Lennart Poettering wrote: On Thu, 14.08.14 17:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: systemd: Copy rules generated while the root was ro Hmm, wut? What's that supposed to be? I think it's glue for running udev when pid 1 != systemd and there was no initramfs. (All the rcS scripts in systemd are either masked or hidden by a corresponding whatever.service on systemd systems anyway, so that particular script is not relevant here.) S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
On Thu, 14.08.14 16:41, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 14/08/14 16:29, Lennart Poettering wrote: On Thu, 14.08.14 17:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: systemd: Copy rules generated while the root was ro Hmm, wut? What's that supposed to be? I think it's glue for running udev when pid 1 != systemd and there was no initramfs. (All the rcS scripts in systemd are either masked or hidden by a corresponding whatever.service on systemd systems anyway, so that particular script is not relevant here.) Hmm, Debian still generates persistent rules at boot? Yuck! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
2014-08-14 17:57 GMT+02:00 Lennart Poettering lenn...@poettering.net: Hmm, Debian still generates persistent rules at boot? Yuck! Correct. We still use the old persistent network naming scheme and have not transitioned to the new scheme [1] yet. We might in the future or not. This needs further investigation and a proper transition plan. At least for jessie we don't want to deal with yet another transition which has the potential to break a lot of existing installations. Cheers, Michael [1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
2014-08-14 17:04 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: On Thu, Aug 14, 2014 at 02:31:00PM +0100, Simon McVittie wrote: On 14/08/14 13:27, Vlad Orlov wrote: ### BEGIN INIT INFO # Provides: mintsystem # Required-Start:$local_fs $syslog $remote_fs dbus # Required-Stop: $local_fs $syslog $remote_fs # Default-Start: S # Default-Stop: ### END INIT INFO As Lennart said, this is Debian-(and-its-derivatives)-specific: upstream systemd does not support sysvinit services during early boot, i.e. rcS. In Debian, support for sysvinit scripts in rcS was patched back in to avoid breaking existing software, because it's unlikely that all of the packages listed in http://codesearch.debian.net/search?q=Default-Start%3A\s*S will get a native systemd unit any time soon. Most of them probably doesn't actually need to run in rcS - nvi? seriously? - but if fixing them all was on the critical path for adopting systemd, we'd probably still be using sysvinit for years to come. Actually, most of them probably don't need to run at all: Yeah, this is correct. Those init scripts are only necessary if you actually still use sysvinit as PID 1. See http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.links -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
On Aug 14, Lennart Poettering lenn...@poettering.net wrote: Hmm, Debian still generates persistent rules at boot? Yuck! Experience shows that it worked better than the alternatives for our users, so I think that we will just keep it around for a while, probably until most hardware will provide persistent names via BIOS tables. -- ciao, Marco signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
