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

[Felipe Sateler]

On 15 January 2016 at 11:09, Frank Heckenbach <f.heckenbach at fh-soft.de> 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