Re: swap on zram service unit, using Conflicts=umount

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 24.06.19 21:01, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote:

> On Mon, Jun 24, 2019 at 6:11 AM Lennart Poettering
> <lennart@xxxxxxxxxxxxxx> wrote:
> > That said, I don't really grok zram, and not sure why there's any need
> > to detach it at all. I mean, if at shutdown we lose compressed RAM
> > or lose uncompressed RAM shouldn't really matter. Hence from my
> > perspective there's no need for Conflicts= at all, but maybe I am
> > missing something?
>
> Huh yeah, possibly if anything there could be low memory systems just
> barely getting by with swap on zram, and even swapoff at reboot time
> would cause it to get stuck. It might just be better to clobber it at
> reboot time?
>
> I'd like to allow a user to 'systemctl stop zram' which does swapoff
> and removes the zram device. But is there something that could go into
> the unit file that says "don't wait for swapoff, if everything else is
> ready for shutdown, go ahead and reboot now?"

Not sure I follow? I mean, it should be enough to say in the .swap
unit for zswap that there is no Conflicts towards a unit like
shutdown.target, umount.target and so on. With that in place we'll
leave the swap device up until the very end, but still allow users to
manually stop it with "systemctl stop" if they like. It's just that
systemd won't do that on its own during shutdown.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel