<p dir="ltr">Control: forwarded -1 <a href="https://github.com/systemd/systemd/issues/2930">https://github.com/systemd/systemd/issues/2930</a><br></p>
<p dir="ltr">On 1 Apr 2016 04:43, "Frank Heckenbach" <<a href="mailto:f.heckenbach@fh-soft.de">f.heckenbach@fh-soft.de</a>> wrote:<br>
><br>
> > On 28 March 2016 at 12:18, Frank Heckenbach <<a href="mailto:f.heckenbach@fh-soft.de">f.heckenbach@fh-soft.de</a>> wrote:<br>
> > > Felipe Sateler wrote:<br>
> > ><br>
> > >> BTW, systemd has been uploaded to proposed-updates[1] fixing #805133.<br>
> > >> Could you please upgrade to that version and try using the<br>
> > >> After=swap.target workaround?<br>
> > ><br>
> > > Actually, I'm not sure if it works. I could not reproduce the bug<br>
> > > now (but it wasn't 100% reproducible anyway).<br>
> > ><br>
> > > However, "systemd-analyze blame" still shows tmp.mount started<br>
> > > before the swap targets. Is this not the right tool to check? Any<br>
> > > other way to check the order dependencies systemd actually uses, so<br>
> > > I can positively verify that it does things in the correct order and<br>
> > > it wasn't just lucky timing?<br>
> ><br>
> > You can check `systemctl list-dependencies --after tmp.mount`<br>
><br>
> OK, this confirms it works correctly.<br>
><br>
> > >> If it works, then using<br>
> > >> overcommit_memory would require adding the After= snippet, and this<br>
> > >> bug could be turned into a documentation bug (but where?).<br>
> > ><br>
> > > It doesn't really depend on overcommit_memory. You get the bug also<br>
> > > with tmpfs usage larger than physical RAM. So if that's the<br>
> > > solution, "After=swap.target" should always be there, i.e. in the<br>
> > > tmp.mount as installed.<br>
> > ><br>
> > > Or is there any case where swapoff needs to be before umount /tmp?<br>
> > > The only possibility I could imagine, in the spirit of<br>
> > > <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1031158">https://bugzilla.redhat.com/show_bug.cgi?id=1031158</a>, is when a swap<br>
> > > file is in a tmpfs, but that's just silly. ;) So I think in most<br>
> > > cases, the order doesn't matter, and if it does, umount before<br>
> > > swapoff is correct. So it shouldn't hurt to always do the ordering.<br>
> ><br>
> > This makes sense to me, but I'll defer to others (in particular, this<br>
> > is probably something best brought up upstream).<br>
><br>
> <a href="https://github.com/systemd/systemd/issues/2930">https://github.com/systemd/systemd/issues/2930</a></p>
<p dir="ltr">Thanks, marking as forwarded.</p>
<p dir="ltr">Saludos<br>
</p>