Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#40972 - [systemd 214-2] Found ordering cycle on multi-user.target/start

Attached to Project: Arch Linux
Opened by Robert Orzanna (orschiro) - Wednesday, 25 June 2014, 13:23 GMT
Last edited by Dave Reisner (falconindy) - Friday, 27 June 2014, 13:37 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

With the latest upgrade to 214-2, I cannot longer boot into my system correctly. I cannot login as normal user on the TTY.

The reported error:

Jun 25 07:09:19 thinkpad systemd[1]: Found ordering cycle on multi-user.target/start
Jun 25 07:09:19 thinkpad systemd[1]: Breaking ordering cycle by deleting job local-fs.target/start
Jun 25 07:09:19 thinkpad systemd[1]: Job local-fs.target/start deleted to break ordering cycle starting with multi-user.target/start

Can someone reproduce this? Downgrading back to 213-9 temporarily resolves the issue.

Steps to reproduce:

1. Upgrade to 214-2
2. Reboot your system
This task depends upon

Closed by  Dave Reisner (falconindy)
Friday, 27 June 2014, 13:37 GMT
Reason for closing:  Not a bug
Comment by Dave Reisner (falconindy) - Wednesday, 25 June 2014, 13:49 GMT
> Can someone reproduce this?
Sounds like you can, but haven't given enough information to actually reproduce the problem. I suspect you have some custom unit somewhere in /etc/systemd/system which is creating your problem.
Comment by Robert Orzanna (orschiro) - Wednesday, 25 June 2014, 15:57 GMT
Could it be maybe an issue due to the timer targets?

system l
total 1M
drwxr-xr-x 2 root root 1M 2012-11-10 22:44:23.994275705 +0100 getty.target.wants
-rw-r--r-- 1 root root 1M 2013-09-17 08:45:12.343326596 +0200 setkeycodes.service
drwxr-xr-x 2 root root 1M 2013-12-11 23:13:16.013642334 +0100 graphical.target.wants
lrwxrwxrwx 1 root root 1M 2014-02-22 21:26:39.168977346 +0100 dbus-org.freedesktop.thermald.service -> /usr/lib/systemd/system/thermald.service
-rw-r--r-- 1 root root 1M 2014-03-21 07:01:00.178676923 +0100 lirc-logitech-r400.service
drwxr-xr-x 2 root root 1M 2014-03-23 08:00:09.372099602 +0100 lirc.service.d
drwxr-xr-x 2 root root 1M 2014-05-05 07:37:18.269206263 +0200 suspend.target.wants
lrwxrwxrwx 1 root root 1M 2014-05-10 22:29:54.812367703 +0200 systemd-backlight@backlight:intel_backlight.service -> /dev/null
-rw-r--r-- 1 root root 1M 2014-05-10 22:30:14.626250306 +0200 xtrlock-on-suspend.service
drwxr-xr-x 2 root root 1M 2014-05-10 22:30:20.813088978 +0200 sleep.target.wants
drwxr-xr-x 2 root root 1M 2014-05-21 07:02:42.820591711 +0200 local-fs.target.wants
-rw-r--r-- 1 root root 1M 2014-05-28 23:41:16.258641394 +0200 dropbox@.service
drwxr-xr-x 2 root root 1M 2014-06-06 09:46:33.249384073 +0200 sysinit.target.wants
-rw-r--r-- 1 root root 1M 2014-06-07 13:02:59.820145362 +0200 rsync-backup.service
-rw-r--r-- 1 root root 1M 2014-06-07 13:08:05.185868755 +0200 timer-weekly.target
drwxr-xr-x 2 root root 1M 2014-06-07 13:08:29.099396810 +0200 basic.target.wants
-rw-r--r-- 1 root root 1M 2014-06-10 23:49:31.244598784 +0200 timer-weekly.timer
drwxr-xr-x 2 root root 1M 2014-06-11 22:10:38.591204343 +0200 timer-weekly.target.wants
-rw-r--r-- 1 root root 1M 2014-06-12 09:36:34.684703815 +0200 flickrsmartsync.service
-rw-r--r-- 1 root root 1M 2014-06-13 18:27:01.922329064 +0200 insync@.service
drwxr-xr-x 2 root root 1M 2014-06-25 07:10:44.580428881 +0200 multi-user.target.wants
Comment by Dave Reisner (falconindy) - Thursday, 26 June 2014, 17:37 GMT
I've no idea what those files are if you've created them yourself. I can only suggest disabling them all and seeing if you still get the broken ordering. When you don't, figure out which one of the units is responsible for introducing it.
Comment by Robert Orzanna (orschiro) - Thursday, 26 June 2014, 21:27 GMT
Sorry for the inaccurate bug report Dave.

Indeed it was caused by my own system. I realised that I had quite a few broken symlinks from orphaned services that I forgot to disable on uninstall of the package.

It's probably out of the scope of the bug tracker to ask this here, but why does systemd not automatically disable services (and thus removes sysmlinks) on uninstall of packages?
Comment by Dave Reisner (falconindy) - Friday, 27 June 2014, 13:36 GMT
I don't believe that dead symlinks caused this. For the same reason that uninstalling a package never modified your /etc/rc.conf, I don't think symlinka should be removed either. Its your /etc, your config.

Loading...