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

[Frank Heckenbach]

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

OK, this confirms it works correctly.

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

https://github.com/systemd/systemd/issues/2930

Regards,
Frank