Unit ordering cycle

[xaverdh]

Issue description

Setting both
boot.tmpOnTmpfs
as well as
zramSwap.enable
results in in an ordering cycle:

sysinit.target: Found ordering cycle on systemd-timesyncd.service/start
sysinit.target: Found dependency on tmp.mount/start
sysinit.target: Found dependency on swap.target/start
sysinit.target: Found dependency on dev-zram0.swap/start
sysinit.target: Found dependency on zram-init-zram0.service/start
sysinit.target: Job systemd-timesyncd.service/start deleted to break ordering cycle starting with sysinit.target/start

..and similar output.

Steps to reproduce

Set both zramSwap.enable and boot.tmpOnTmpfs to true.

Technical details

Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

• system: "x86_64-linux"
• host os: Linux 4.18.10, NixOS, 19.03pre153673.a70d3bab72d (Koi)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.1.2
• channels(root): "nixos-19.03pre153673.a70d3bab72d"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

[chasevasic]

I want to comment that I have this same problem occurring on NixOs 19.09.

I also have another problem which is that my tmpfs /tmp is getting mounted way too late, causing issues. I ran into this while investigating the /tmp issue. I don't yet know if they are connected or similar though. In my case, /tmp gets mounted after X starts, which causes problems down the line when applications cant find /tmp/.X11-unix or /tmp/xauth-*

@xaverdh , have you noticed a similar issue with /tmp being mounted late? Also, have you found any fix or workaround since you posted this? I am looking into fixes myself, since zram and tmpfs /tmp are features which I have incorporated into my system configuration for years and I don't want to disable.

[xaverdh]

I don't have any real issues, although tmp.mount complains, that
"Directory /tmp to mount over is not empty, mounting anyway."
, so I guess in principle there could/should be issues.

I didn't find any fix till now, but its not my top priority atm.

[fuzzy-id]

Similar issue here:

• system: "x86_64-linux"
• host os: Linux 4.14.81, NixOS, 18.09.1363.b37872d4268 (Jellyfish)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.1.3
• channels(root): "nixos-18.09.1363.b37872d4268"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Log says:

Nov 19 13:02:41 bahru systemd[1]: sysinit.target: Found ordering cycle on systemd-timesyncd.service/start
Nov 19 13:02:41 bahru systemd[1]: sysinit.target: Found dependency on tmp.mount/start
Nov 19 13:02:41 bahru systemd[1]: sysinit.target: Found dependency on swap.target/start
Nov 19 13:02:41 bahru systemd[1]: sysinit.target: Found dependency on dev-zram1.swap/start
Nov 19 13:02:41 bahru systemd[1]: sysinit.target: Found dependency on zram-init-zram1.service/start
Nov 19 13:02:41 bahru systemd[1]: sysinit.target: Found dependency on zram-reloader.service/start
Nov 19 13:02:41 bahru systemd[1]: sysinit.target: Found dependency on basic.target/start
Nov 19 13:02:41 bahru systemd[1]: sysinit.target: Found dependency on sockets.target/start
Nov 19 13:02:41 bahru systemd[1]: sysinit.target: Found dependency on dbus.socket/start
Nov 19 13:02:41 bahru systemd[1]: sysinit.target: Found dependency on sysinit.target/start
Nov 19 13:02:41 bahru systemd[1]: sysinit.target: Job systemd-timesyncd.service/start deleted to break ordering cycle star>

[chasevasic]

The main problem for me is that the "tmp.mount" unit gets started after X starts. Then I eventually run into applications crashing or not starting because the X11 sockets in /tmp are missing. This ties back to an age old issue with Linux which is that unix sockets have no standard location. Rather than moving sockets out of tmp, I think it's much better to get tmp mounted as early as possible.

The reason tmp is not mounting early as it is supposed to, is that someone has decided to make tmp.mount depend on swap.target, which in turn depends on dev-zram.swap . I suspect that the reasoning for this, is either that tmpfs can only access swaps which are already active (I'm not sure if this is the case), or on systems without very much ram zram allows tmpfs to be bigger since it will be compressed.

On my system, there is no need for /tmp to require zram. It would be nice, since /tmp tends to contain text files which benefit from compression. But it is not necessary.

The solution I would like to accomplish is simply removing the zram dependency from tmp.mount . Currently I am not sure what the best way to do this is. For it to be a proper solution, I think there should also be a switch which toggles whether tmp.mount requires zram, since some people might need that to be the case.

In the meantime, the workaround which has fixed problems I'm having is to move everything from the root filesystem tmp to the new tmpfs tmp after it's been mounted. For me this means mounting my root device in a directory like /mnt then moving /mnt/tmp/* to /tmp/ after /tmp is mounted.

It might be worth looking at the solutions other distros have. I used zram and tmpfs /tmp on both Arch and Gentoo without any problems like this. I believe that I had a simpler zram configuration which just involved loading the kernel module and putting a line in fstab.

[clacke]

I suspect that the reasoning for this, is either that tmpfs can only access swaps which are already active (I'm not sure if this is the case)

Sounds very odd and unlikely to me.

or on systems without very much ram zram allows tmpfs to be bigger since it will be compressed.

It's unlikely that it would require the extra size during boot.

Would be great if someone could explain the reason for the dependency.

tmp.nix was added back in 2014 and has never been modified, and it seems to be just activating a service that comes with systemd, so it's unlikely that someone here has actually made the decision to make tmp.mount depend on swap.target, that reasoning needs to be found in the systemd history.

[chasevasic]

Unfortunately, for now I have opted to simply disable tmpfs /tmp . I was convinced by this thread on the Debian mailing list https://lists.debian.org/debian-devel/2012/06/msg00311.html . It's possible for me to get the applications I want using tmpfs rather than disk-based temporary storage in other ways than mount tmpfs on /tmp. In the past, it has been better for me to use tmpfs tmp, because it works for multiple applications, and felt like a clean solution on other distros. In my case, the purpose behind using tmpfs here is mostly for somewhat-large file (or files that could end up being large) which are slow on hard-drive and wasteful on solid-state.

---

Would be great if someone could explain the reason for the dependency.

tmp.nix was added back in 2014 and has never been modified, and it seems to be just activating a service that comes with systemd, so it's unlikely that someone here has actually made the decision to make tmp.mount depend on swap.target, that reasoning needs to be found in the systemd history.

I really am not sure, but to me, it seems that the dependency issue does not come from the systemd unit or tmp.nix, it comes from zram.nix
On other systems I setup zram with a simpler systemd unit and an entry in fstab.

If it helps anyone, here are the messages I have logged from this issue:

systemd[1]: sysinit.target: Found ordering cycle on systemd-timesyncd.service/start
systemd[1]: sysinit.target: Found dependency on tmp.mount/start
systemd[1]: sysinit.target: Found dependency on swap.target/start
systemd[1]: sysinit.target: Found dependency on dev-zram0.swap/start
systemd[1]: sysinit.target: Found dependency on zram-init-zram0.service/start
systemd[1]: sysinit.target: Found dependency on basic.target/start
systemd[1]: sysinit.target: Found dependency on sockets.target/start

Looking further, I ran this:

# systemctl list-dependencies sockets.target
sockets.target
● ├─docker.socket
● ├─nix-daemon.socket
● ├─systemd-initctl.socket
● ├─systemd-journald-audit.socket
● ├─systemd-journald-dev-log.socket
● ├─systemd-journald.socket
● ├─systemd-udevd-control.socket
● ├─systemd-udevd-kernel.socket
● ├─virtlockd.socket
● └─virtlogd.socket

which shows sockets.target includes nix-daemon.socket, if you look at nix-daemon.socket, it requires systemd-timesyncd.service
So this is the cycle that is being referenced by the systemd messages.

I'm still not sure of a proper solution. It seems to me that this problem should occur any time someone enables both zram and tmpfs tmp on NixOs though, so worst case, this problem could be documented and people could know to avoid mixing those settings, or maybe they could be mutually exclusive options. Of course, it would be better to fix the dependency cycle, but I personally don't know the right way to do it.

[danbst]

@chasevasic @xaverdh can you look into #52991? I've removed hard binding to swap devices for zram and I can't reproduce this issue.

[xaverdh]

I still have the same issue with tmpOnTmpfs + zram.

[danbst]

Right, I did reproduce. Added a patch to that PR, so it should fix this problem as well

[xaverdh]

I can confirm, that the patch resolves the dependency cycle.