[systemd-devel] `Found ordering cycle on _SERVICE_` loops due to `local-fs.target` with `Requires` instead of `Wants` for mounts generated from `/etc/fstab`
John Florian
john at doubledog.org
Fri Apr 27 13:13:30 UTC 2018
On 2018-04-27 03:56, Jérémy Rosen wrote:
> Ok, there are a couple of tools that have not be mentionned..
>
> "systemd-analyze verify <service>" will check all sorts of stuff on a
> service, including checking recursively the deps and finding ordering
> cycles
>
>
> systemctl list-dependencies can show ordering/req dependencies, up or
> down, recursively or not
>
> to be completely honest, I never use dot for cycles.... I sometime
> read/grep the .dot file itself, but I never generate the image...
>
> systemd-analyze is my favorite tool for that sort of problems
>
> On 27/04/2018 06:01, Andrei Borzenkov wrote:
>> Well, you could use "systemctl show -p Id -p After -p Before" but the
>> problem is to find the correct unit set. You really need something that
>> simulates transaction and evaluates dependencies like systemd does it.
>>
>> Note that systemd should print offending cycle when it hits it:
>>
>> апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found
>> ordering cycle on foo.service/start
>> апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found
>> dependency on bar.service/start
>> апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found
>> dependency on baz.service/start
>> апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found
>> dependency on foo.service/start
>> апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Breaking
>> ordering cycle by deleting job baz.service/start
Well these are good things to know. I can't recall if I ever tried to
use them when faced with a loop. I'd guess that I tried
`systemd-analyze verify` as it sort of jumps off the man page whereas
`systemctl list-dependencies` is kind of buried in the details.
>> It would be helpful it if additionally printed kind of dependency (like
>> foo.service is After bar.service) because this is by far not obvious for
>> average user.
Maybe one really helpful immediate change would be to have systemd log
some hints when it breaks a loop to suggest a few commands that might be
run to help understand the situation more clearly.
More information about the systemd-devel
mailing list