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

[Felipe Sateler]

On 14 January 2016 at 14:35, Frank Heckenbach <f.heckenbach at 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