In Fedora udev-retry.service exists both as a native unit and as a
legacy SysV service. The ordering inferred from the rc.d symlink farm is
being incorrectly applied to the native unit:

$ systemctl show -p After -p Before udev-retry.service
Before=basic.target dnsmasq.service netconsole.service irda.service 
smolt.service mysqld.service exim.service
After=local-fs.target udev.service restorecond.service sandbox.service 
ypbind.service auditd.service ebtables.service rpcbind.service 
speech-dispatcherd.service

This causes ordering cycles such as this one:
 Found ordering cycle on basic.target/start
 Walked on cycle path to udev-retry.service/start
 Walked on cycle path to auditd.service/start
 Walked on cycle path to basic.target/start
 Breaking ordering cycle by deleting job udev-retry.service/start

This patch fixes it by clearing the SysV priority of the service after it is
known to be native. With this patch there is no ordering cycle and only the
dependencies listed in the native unit file are present:

$ systemctl show -p After -p Before udev-retry.service
Before=basic.target
After=local-fs.target udev.service
---

 src/service.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/src/service.c b/src/service.c
index 1735a96..a2388a7 100644
--- a/src/service.c
+++ b/src/service.c
@@ -1096,9 +1096,15 @@ static int service_load(Unit *u) {
 
 #ifdef HAVE_SYSV_COMPAT
         /* Load a classic init script as a fallback, if we couldn't find 
anything */
-        if (u->meta.load_state == UNIT_STUB)
+        if (u->meta.load_state == UNIT_STUB) {
                 if ((r = service_load_sysv(s)) < 0)
                         return r;
+        } else
+                /* It is native. Since we may have found a legacy service of
+                 * the same name in service_enumerate() earlier, clear the SysV
+                 * priority now to prevent polluting the unit with SysV
+                 * ordering dependencies. */
+                s->sysv_start_priority = -1;
 #endif
 
         /* Still nothing found? Then let's give up */

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to