On 15 January 2016 at 11:09, Frank Heckenbach <[email protected]> wrote: >> > 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... > > Not really. overcommit_memory is a simple, static setting > /etc/sysctl.d/local.conf whereas as I said the tmpfs change is > rather long and system-dependent (if you have a solution for > auto-generating it, let me know). > > I suggest we keep this bug open until it's fixed in stable (and I > keep using my work-around until then). When it's done, I can try > "After=swap.target" and report if it works.
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? 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?). [1] https://www.debian.org/releases/proposed-updates.html -- Saludos, Felipe Sateler
