> > 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.
