[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Some services cannot start at boot time because /run is not initialized



On 2021-04-22 14:26 +0200, Dmitry Katsubo wrote:

> Dear Debian community,
>
> I have noticed that all failed services were missing some directories under /run directory. I checked the service which is supposed to create them:
>
> *  systemd-tmpfiles-setup.service - Create Volatile Files and Directories
>    Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor preset: enabled)
>    Active: inactive (dead)
>      Docs: man:tmpfiles.d(5)
>            man:systemd-tmpfiles(8)
>
> systemd[1]: sysinit.target: Found ordering cycle on systemd-tmpfiles-setup.service/start
> systemd[1]: sysinit.target: Found dependency on local-fs.target/start
> systemd[1]: sysinit.target: Found dependency on zram-setup@zram1.service/start
> systemd[1]: sysinit.target: Found dependency on sysinit.target/start
> systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with sysinit.target/start

This is obviously bad, since many files and directories under /run will
be missing.

> and it looks like there is problem in zram-setup@zram1.service which I configured like that:
>
> [Unit]
> Requires=dev-%i.device
> After=dev-%i.device
> Before=local-fs.target
> [Install]
> WantedBy=local-fs.target
>
> # systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After local-fs.target
> Requires=home.mount -.mount var.mount
> Requisite=
> Wants=systemd-fsck-root.service zram-setup@zram0.service zram-setup@zram1.service systemd-remount-fs.service
> BindsTo=
> PartOf=
> Before=binfmt-support.service sysinit.target systemd-machine-id-commit.service systemd-tmpfiles-setup.service networking.service systemd-tmpfiles-clean.service console-setup.service
> After=run-user-1000.mount zram-setup@zram0.service root.mount -.mount tmp.mount zram-setup@zram1.service systemd-fsck-root.service systemd-remount-fs.service home.mount var.mount local-fs-pre.target
>
> Even though I don't see any conflict with dependencies, it is confusing systemd.
>
> Any idea concerning how to fix that is welcomed.

I think you need to add a line with

DefaultDependencies=no

to the [Unit] section of your .service file.  That is because by
default, all services have an implicit dependency on sysinit.target (see
systemd.target(5)), and sysinit.target depends on local-fs.target:

,----
| $ systemctl show -p WantedBy local-fs.target
| WantedBy=sysinit.target
`----

HTH,
    Sven


Reply to: