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