[systemd-devel] [SPAM]Re: Mount units with After=autofs.service cause ordering cycles

[John Florian]

On 10/31/19 2:59 PM, Lennart Poettering wrote:
> On Do, 31.10.19 14:09, John Florian (jflorian at doubledog.org) wrote:
>
>>>> # /etc/systemd/system/var-www-pub.mount
>>>> [Unit]
>>>> Description=mount /pub served via httpd
>>>> Requires=autofs.service
>>>> After=autofs.service
>>>>
>>>> [Mount]
>>>> What=/mnt/pub
>>>> Where=/var/www/pub
>>>> Options=bind,context=system_u:object_r:httpd_sys_content_t
>>>>
>>>> [Install]
>>>> WantedBy=multi-user.target
>>>>
>>>> ~~~
>>>>
>>>> The above worked for a long time, but once again a `dnf upgrade` seems to
>>>> have broken things because now I have a ordering cycle that systemd must
>>>> break.  Since I haven't changed my mount units, my ability to mesh with
>>>> those shipped by the OS proves fragile. I'm deliberately avoiding too much
>>>> detail here because it would seem that there should be a relatively simple
>>>> solution to this general sort of task -- I just can't seem to discover it.
>>>> Any recommendations that don't involve an entirely different approach?
>>> What precisely is the ordering cycle you are seeing? It's usually
>>> dumped along with the log message.
>> systemd[1]: local-fs.target: Found ordering cycle on var-www-pub.mount/start
>> systemd[1]: local-fs.target: Found dependency on autofs.service/start
>> systemd[1]: local-fs.target: Found dependency on rpc-statd.service/start
>> systemd[1]: local-fs.target: Found dependency on network-online.target/start
>> systemd[1]: local-fs.target: Found dependency on network.target/start
>> systemd[1]: local-fs.target: Found dependency on
>> NetworkManager.service/start
>> systemd[1]: local-fs.target: Found dependency on sysinit.target/start
>> systemd[1]: local-fs.target: Found dependency on
>> systemd-update-done.service/start
>> systemd[1]: local-fs.target: Found dependency on local-fs.target/start
>> systemd[1]: local-fs.target: Job var-www-pub.mount/start deleted to break
>> ordering cycle starting with local-fs.target/start
> The ordering dep between local-fs.target and var-ww-pub.mount is what
> you have to get rid of to remove the cycle. Set:
>
> …
> [Unit]
> DefaultDependencies=no
> Conflicts=umount.target
> Before=umount.target
> …
> [Install]
> WantedBy=remote-fs.target
> …
>
> i.e. make this a dep of remote-fs.target, not the implicit
> local-fs.target, so that we don#t pull it in early boot, but only
> during late boot, before remote-fs.target.

Thanks Lennart!  That did the trick.  I and others I know have knocked 
heads on this one several times and somehow never came to this 
conclusion.  It makes sense now that I see it, however. <shrugs/>  Maybe 
local-fs.target should have stood out to me, but I think it was mostly 
accepted since if you follow all deps far enough, you'll eventually 
cover (most?) everything.

I think this just means I need to use `systemctl show` more even though 
`systemctl cat` is so much easier to digest for what I think I need to 
know.  Abstracting the default deps is both good in expression but also 
difficult in comprehension.  I wish there was something "in between", 
but I don't even know how to define what that means.  Maybe just 
grouping all the settings from `show` somehow, e.g.: ordering, deps, 
etc. or maybe by unit type: unit, exec, mount, etc.