[systemd-devel] How to prevent an initramfs service from being stopped at switch-root ?

[John Lane]

On 11/01/16 16:44, Lennart Poettering wrote:
> On Mon, 11.01.16 13:38, John Lane (systemd at jelmail.com) wrote:
>
>> On 11/01/16 13:09, Tomasz Torcz wrote:
>>> On Mon, Jan 11, 2016 at 12:39:10PM +0000, John Lane wrote:
>>>> I have some services in my initramfs that unlock some crypto volumes to
>>>> make the root and some other filesystems available.
>>>   This seems relevant:
>>> https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/
>>>
>> Yeah, I read that. But it doesn't explain how to configure a unit. I
>> read the bit about processes where the first character of the zeroth
>> command line argument is '@' are excluded from the killing spree, but
>> not sure how to do that from a unit specification file.
> This should be done by the daemons themselves. It's really nothing you
> can do properly from the outside.
>
> If daemons shall run from the initrd, they must be prepared for that,
> for example never access /var and not assume tmpfiles was run or
> suchlike. They must be able to deal with the root file directory being
> pivoted away and suchlike. hence: it's really not as easy as just
> taking a daemon and calling it slightly differently -- instead the
> daemon must be designed for this mode of operation, in which case it
> should implement the @ logic natively.
>
> Lennart
>
Let me explain my scenario to you, perhaps I am doing something wrong...

I have a "cryptsetup at .service" that is symlinked as
cryptsetup at some_disk.service that unlocks a crypto-disk containing the
root filesystem. Mounts then happen as they should, and everything works.

Then, when the switch root happens, systemd tries to kill the above
service. This fails because it is busy due to the underlying filesystem
being mounted. This leaves the unit in a failed state. After the switch
root, systemd tries to start the unit but this fails because the device
mapper is already assigned. The net result is the system's always
"degraded" with "cryptsetup at some_disk.service" in a failed state
(despite everything being fine).

I'm using a cryptsetup at .service unit instead of /etc/crypttab because I
needed to use cryptsetup options that the latter didn't support when I
implemented it.