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

Frank Heckenbach f.heckenbach at fh-soft.de
Mon Mar 28 16:18:24 BST 2016


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




More information about the Pkg-systemd-maintainers mailing list