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

[Felipe Sateler]

On 28 March 2016 at 12:18, Frank Heckenbach <f.heckenbach at fh-soft.de> wrote:
> 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?

You can check `systemctl list-dependencies --after tmp.mount`

>> 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.

This makes sense to me, but I'll defer to others (in particular, this
is probably something best brought up upstream).

-- 

Saludos,
Felipe Sateler