Let the swap unit remain survive shutdown

[keszybz]

Swap units have automatic dependencies of Before=swap.target,shutdown.target, Conflicts=shutdown.target. By adding DefaultDependencies=no, Before=swap.target, we effective drop the negative dependency with shutdown.target and allow the swap device to survive shutdown.

There is no need to bring down the swap device during shutdown. This wastes work, because any remaning pages need to be dropped or decompressed and moved to normal memory. Normally this is very quick, but the report says that it takes 15–20 seconds in their case.

Closes #191.

[nabijaczleweli]

The formatting's a little off, but whatever. I don't think this interferes with, like, hibernation? so I can't see any contra-indicators. Great to see this.

[nabijaczleweli]

Actually, can we writeback to files? What happens then?

[keszybz]

The formatting's a little off, but whatever.

We (I really) started using more whitespace in formatting of unit files in upstream systemd. The original style was maximally compressed, but it turns out that (unsurprisingly) things a much more readable if the settings are groupped by purpose, and the same or similar order is used in multiple unit files. Thus I'm trying to have a block for Description, a block for important settings, and a block for Before/After/Requires/Wants deps, and the ordering and requirement deps are interleaved so that the settings referrering to the same unit are adjacent. Long story short, the whitespace change here is intentional.

Actually, can we writeback to files? What happens then?

I think this should be fine. If the writeback file needs to be destroyed, then the dependencies from the side of the device should cause the swap to be stopped, and the zram device destroyed.

Hibernation is not really important. In hibernation, the contents of RAM are saved to storage, and if some of them are zram, this shouldn't really matter. A zram device survives hibernation.

[nabijaczleweli]

It reads weird to me because in my head DefaultDependencies= ought to be like a header for the depends/wants/&c. block and it doesn't read like that to me. But, whatever.

My thinking is that the default Conflicts= is umount.target and now we don't, and we have BindsTo=dev-loop0.device, which mangles the filesystem dependency? So we're keeping, say /var/writeback <- /dev/loop0 <-> /dev/zram0, so /var can never be unmounted because there's no valid dependency chain to it? Maybe? You understand this better than I.

[keszybz]

Dependency chains work both ways. If you say umount /var, then systemd should be able to figure out that it needs to kill /dev/loop0 and /dev/zram0. Though it'd be good to verify this of course.

[nabijaczleweli]

I'm concerned because I haven't been able to find a field thst would link dev-loop0.device to anything /var-shaped. I may be looking wrong of course.

[nabijaczleweli]

To wit: $ systemctl list-dependencies dev-loop0.device --all dev-loop0.device

[nabijaczleweli]

trixie systemd apparently has gained these udev properties that weren't in bookworm:

E: ID_LOOP_BACKING_DEVICE=0:34
E: ID_LOOP_BACKING_INODE=39210
E: ID_LOOP_BACKING_FILENAME=/tmp/dir/tname": "rozbian",
E: ID_LOOP_BACKING_FILENAME_ENC=\x2ftmp\x2fdir\x2ftname\x22:\x20\x22rozbian\x22\x2c

but still doesn't forward them to BindsTo=.

systemd/systemd#35303

[keszybz]

The case of devices with writeback is fairly niche. So I think it's fine if we change behaviour only for the normal devices without writeback.

[keszybz]

OK, I tested this with a VM, and it doesn't seem to cause any adverse effects.

[nabijaczleweli]

That's a solid solution as well.