On 14 January 2016 at 14:35, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: >> Due to the other bug I linked, this may not be sufficient. Please list >> all the swap units listed in >> >> % systemctl list-units '*.swap' >> >> You'll see that there are multiple units each of the different ways >> you can access the underlying partition (by uuid, did, wwm and sdX >> name). >> >> I don't think you need to quote differently. > > This seems to work. However, given that this single line is now >1 > KB and more than 3 times as long as my work-around service, and > heavily depends on the system configuration, I doubt whether it's > actually less hackish. (I do occasionally change my swap partitions. > I also build system images to run on different machines.) > > One could try to auto-generate this, of course. Not too hard, but > when should it run? From a systemd service run during boot, which > modifies another systemd run during boot -- doesn't seem like a good > idea. (And it would break if swap partitions are added/removed after > boot.) > > So I'll stick with my work-around, but I think the above can perhaps > serve as an example for what to do in systemd interally (the only > place I could image it working reliably), maybe similar to the patch > in https://github.com/systemd/systemd/issues/1902 (but I don't know > the internals well enough to really tell).
Once this package is fixed in stable, the workaround can be reduced to After=swap.target. I don't think we want to diverge locally (ie, in Debian) from what dependencies are automatically added to tmpfs mounts. I figure if you change overcommit_memory you can also specify the tpmfs ordering... This is an issue probably best taken upstream. -- Saludos, Felipe Sateler
