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

[Felipe Sateler]

Control: forwarded -1 https://github.com/systemd/systemd/issues/2930

On 1 Apr 2016 04:43, "Frank Heckenbach" <f.heckenbach at fh-soft.de> wrote:
>
> > 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

Thanks, marking as forwarded.

Saludos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20160401/1065bfb7/attachment.html>