Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

Felipe Sateler wrote:

> BTW, systemd has been uploaded to proposed-updates[1] fixing #805133.
> Could you please upgrade to that version and try using the
> After=swap.target workaround?

Actually, I'm not sure if it works. I could not reproduce the bug
now (but it wasn't 100% reproducible anyway).

However, "systemd-analyze blame" still shows tmp.mount started
before the swap targets. Is this not the right tool to check? Any
other way to check the order dependencies systemd actually uses, so
I can positively verify that it does things in the correct order and
it wasn't just lucky timing?

> If it works, then using
> overcommit_memory would require adding the After= snippet, and this
> bug could be turned into a documentation bug (but where?).

It doesn't really depend on overcommit_memory. You get the bug also
with tmpfs usage larger than physical RAM. So if that's the
solution, "After=swap.target" should always be there, i.e. in the
tmp.mount as installed.

Or is there any case where swapoff needs to be before umount /tmp?
The only possibility I could imagine, in the spirit of
https://bugzilla.redhat.com/show_bug.cgi?id=1031158, is when a swap
file is in a tmpfs, but that's just silly. ;) So I think in most
cases, the order doesn't matter, and if it does, umount before
swapoff is correct. So it shouldn't hurt to always do the ordering.

Regards,
Frank