Re: Problem with systemd and cryptsetup - how to solve it the systemd way?
On Thu, Dec 10, 2015 at 02:38:02PM +0100, Anders Andersson wrote:
> ---- /var/run/systemd/generator/systemd-cryptsetup@crypt.service ----
Do you know whether that is persistent? I used the generator to create
the service file, but I then put the service file into /etc/systemd/user
and removed the crypttab file altogether.
> After this I try starting the new device:
> root@jessie:~# systemctl start dev-mapper-crypt.device
> Please enter passphrase for disk VBOX_HARDDISK (crypt)! ****
> ... here it stalls for what is likely 90 seconds ...
> Job for dev-mapper-crypt.device timed out.
> root@jessie:~#
Did you type the passphrase when prompted? I find the prompt a little
awkward, as it seems to be to every PTY and TTY by default.
> Ok. It kinda failed but not really. The device has been unlocked and
> exists in /dev/mapper/ as expected.
^ This would imply that you did type the passphrase correctly, but
> systemd-ask-password-console.service stop-sigterm timed out. Killing.
^ this would suggest that the passphrase-issuing didn't complete.
Is it possible you left it open from your manual playing when you tried
starting the systemd job, by accident, and systemd had not created the
/dev/mapper/crypt device?
> My question is thus: How am I supposed to solve this the "systemd
> way"? I want to be able to start an encrypted block device using a
> normal systemd service/device so that I can later have systemd units
> depend on this.
So in theory what you've done should work for the first part, and you
would then need to create .mount units that depend on the crypt device,
like this (examples cribbed from my system doing exactly this):
> [Unit]
> RequiresOverridable=systemd-fsck@dev-mapper-docker\x2dfront.service
> After=systemd-fsck@dev-mapper-docker\x2dfront.service
> [Mount]
> What=/dev/mapper/docker-front
> Where=/var/lib/docker
> Type=btrfs
> Options=defaults,noauto
and then you would manually start *this unit* to automatically trigger
the dependency and systemd would prompt you for the passphrase:
> # systemctl start /var/lib/docker
> Please enter passphrase for disk qusp_vg-docker--back (docker-front) on /var/lib/docker! ***
(two points: one, my real passphrase is more than 3 characters. Second,
notice that I can use the FS path as the unit name - systemd can recognise
it and convert it into the right name var-lib-docker.mount. I find this more
convenient than remembering systemd's esoteric escaping rules.)
> # systemctl status /var/lib/docker
> ● var-lib-docker.mount - /var/lib/docker
> Loaded: loaded (/etc/fstab)
> Active: active (mounted) since Fri 2015-12-11 09:57:43 GMT; 9s ago
> Where: /var/lib/docker
> What: /dev/mapper/docker-front
> Process: 21422 ExecMount=/bin/mount -n /dev/mapper/docker-front /var/lib/docker -t btrfs -o defaults,noauto (code=exited, status=0/SUCCESS)
> # systemctl status 'systemd-fsck@dev-mapper-docker\x2dfront.service'
> ● systemd-fsck@dev-mapper-docker\x2dfront.service - File System Check on /dev/mapper/docker-front
> Loaded: loaded (/lib/systemd/system/systemd-fsck@.service; static)
> Active: active (exited) since Fri 2015-12-11 09:57:43 GMT; 1min 2s ago
> Process: 21416 ExecStart=/lib/systemd/systemd-fsck %f (code=exited, status=0/SUCCESS)
> Main PID: 21416 (code=exited, status=0/SUCCESS)
I've only just started doing this myself. I have additional dependencies set up
so my docker daemon depends on the mount (and isn't started on boot), but I haven't
gone further with more mounts etc. yet.
(notice that my crypttab service file has a really awkward name. That's because
I used a dash in the source and destination device names: docker-back, docker-front,
which systemd escapes. It's a bit unwieldy on the shell, I have to quote every use
so the shell doesn't expand \x2d itself, so I'd recommend avoiding using dashes in
device names with systemd.)
--
Jonathan Dowland
Reply to: