[systemd-devel] Raid device issue

[Zbigniew Jędrzejewski-Szmek]

On 12/08/2011 10:00 PM, Ken Bass wrote:
> On 12/8/2011 3:45 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> maybe I'm misunderstanding you, but I think that you are looking at
>> the meaning of cryptsetup.target in a wrong way: cryptsetup.target
>> comes after all encrypted devices configured in /etc/crypttab are
>> ready. So it makes sense to do something with After=cryptsetup.target
>> (== after all encrypted devices have been opened), but not with
>> Before=cryptsetup.target.
>>
>> I guess that you might have to declare the ordering dependence between
>> mnt-subkey.mount with Before=cryptsetup at encrypt_storage.service directly.
>
> Hi Zbyszek,
>
> I understand what you are saying and perhaps I am looking at it from a
> different angle. But the problem with your suggestion is that it is a
> non-generic way to handle it. The 'cryptsetup at encrypt_storage.service '
> is completely dependent on whatever is listed in the /etc/crypttab and
> that could be changed by the user at any time. If that /etc/crypttab
> entry was renamed or commented out, the dependency would mysteriously
> break. Maybe there needs to be a cryptsetup-begin.target and
> cryptsetup-done.target instead? I don't think its is far stretch to want
> to ensure some happens before ANY encrypted devices has been opened.
Hi Ken,

I think that there's a better solution: to make the 
cryptsetup at ....service wait for the appearance of the key file.
The generator could be changed for cases only when the keyfile is 
specified.
Something like this:

== cryptsetup at ...crypt.service ==
[Unit]
ConditionPathExists=/somewhere/keyfile

An additional path unit would need to be created:
== cryptsetup at ...crypt.path ==
[Path]
PathExists=/somewhere/keyfile

I've done some testing with a normal service and a file in /tmp, and it 
seems to behave properly -- since the service has RemainAfterExit=true, 
it can safely be started multiple times.

One problem (potentially fatal :( ) with this setup is that the 
cryptsetup at ...service doesn't wait for they keyfile, but instead first 
fails, and then is started when the path unit condition triggers after 
the file is created. This means that you would properly get the 
decrypted device created after the key file and the encrypted block 
device are available, but it would not be subject to normal timeout.

OK, I now see that this is very hacky, but maybe it will give you some 
useful idea.

Best,
Zbyszek