[systemd-devel] [PATCH] cryptsetup-generator: avoid ordering cycle on swap

[Frederic Crozat]

Le mardi 01 novembre 2011 à 23:53 +0100, Lennart Poettering a écrit :
> On Mon, 17.10.11 17:28, Tom Gundersen (teg at jklm.no) wrote:
> 
> > 
> > On Mon, Oct 17, 2011 at 4:24 PM, Lennart Poettering
> > <lennart at poettering.net> wrote:
> > > On Mon, 17.10.11 13:01, Tom Gundersen (teg at jklm.no) wrote:
> > >
> > >> Devices with random keys (swap), should not be ordered before local-fs.target,
> > >> as this creates a cycle with systemd-load-random-seed.service (and also it
> > >> does not make sense, a swap device is not a local-fs).
> > >
> > > Hmm, your patch makes some sense, but I believe we need to be careful
> > > here: we probably shouldn't try to boot up the machine without swap
> > > activated. Noawadays swap makes little sense unless you have a memory
> > > constrained system, and on those system it's probably quite important to
> > > activate swap before we begin with starting the full memory intensive
> > > snafu.
> > 
> > My understanding was that since dev-mapper-swap.device would only
> > appear after cryptsetup at swap.service has finished we have an implicit
> > ordering:
> > 
> > cryptsetup at swap.service -> dev-mapper-swap.device ->
> > dev-mapper-swap.swap -> swap.target
> 
> Indeed, you are right. 
> 
> > > Could you rework the patch to order the activation of the crypto volumes
> > > before swap.target if they are to be sued for swapping? I think it would
> > > make a lot of sense to have all fs luks before local-fs.target still,
> > > and all swap luks before swap.target. I'll then merge the patch
> > > right-away.
> > 
> > If I understand correctly, one can use a random key to create a
> > temporary filesystem, so we cannot simply order all devices using a
> > random key before swap.target. However, if we order the swap devices
> > before swap.target and the tmp devices before local-fs.target, then
> > the latter will still have an ordering cycle. Come to think of it,
> > wouldn't any tmp device always end up in a cycle (following the same
> > reasoning as above)?
> > 
> > dev-mapper-tmp.device -> tmp.mount -> local-fs.target ->
> > systemd-random-seed-load.service -> cryptsetup at tmp.service
> 
> Yes, you are right. And I have no idea how we should fix that in a
> pretty way. Thankfully not many folks are using this feature for now,
> but it deserves to be fixed nonetheless.
> 
> For now I have applied your original patch and added an entry to the
> TODO list.

Unfortunately, I've just discovered this fix is needed but not
sufficiant :
- it works for encrypted swap
- it doesn't work for encrypted tmp (using /dev/urandom as password),
since /tmp is a needed dependency for local-fs.target, so, it causes a
similar dependency loop, between local-fs.target,
systemd-random-seed-load.service and cryptsetup.target and tmp.mount

Except it is not seen as a loop by systemd (so, it is not broken by
cycle breaker) and instead, a timeout is set on tmp.mount which fails
after 180s.

So far, the only solution I found is to "patch" on the fly
systemd-random-seed-load.service, using a generator, to remove
local-fs.target from After= list, when /dev/*random is specified
in /etc/crypttab. Not very pretty, better suggestions welcome ;)


-- 
Frederic Crozat <fcrozat at suse.com>
SUSE