Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

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