We should GC .device unit jobs from the run queue when nothing depends on them anymore.

[PhilPotter]

Submission type

• Bug report
• Request for enhancement (RFE)

systemd version the issue has been seen with

Version 229

Used distribution

Fedora 24

In case of bug report: Expected behaviour you didn't see

When mapping two LUKS devices on boot with /etc/crypttab, the system should boot completely, with no pending jobs in the 'activating (tentative)' state.

In case of bug report: Unexpected behaviour you saw

Systemd still thinks it is perpetually booting, and running systemd-analyze gives the output "Bootup is not yet finished. Please try again later.". Running systemctl list-jobs shows that the first item is still running:
JOB UNIT TYPE STATE
165 dev-mapper-stuff_array1.device start running

1 jobs listed.

And systemctl status dev-mapper-stuff_array1.device shows:
dev-mapper-stuff_array1.device - /dev/mapper/stuff_array1
Loaded: loaded
Drop-In: /run/systemd/generator/dev-mapper-stuff_array1.device.d
ââ90-device-timeout.conf
Active: activating (tentative) since Tue 2016-11-08 11:30:57 GMT; 30min ago
Device: /sys/devices/virtual/block/dm-0

The strange thing is that outwardly the system does appear to boot fully and is completely usable as a desktop. The two devices (/dev/sdb and /dev/sdc) are automatically unlocked and mapped to /dev/mapper/stuff_array1 and /dev/mapper/stuff_array2 and the BTRFS volume is mounted via fstab with no problems. The root device is an OPAL volume which is unlocked via PBA on boot, but this problem existed prior to this also. It seems this problem has existed for others but I don't seem to have found a solution, other than just taking the entries out of /etc/crypttab and unlocking and mounting the volume manually, which then allows system-analyze to work.

In case of bug report: Steps to reproduce the problem

I have two hard disk block devices, /dev/sdb and /dev/sdc - this problem also exists when I use partitions rather than the whole block device. Both /dev/sdb and /dev/sdc are setup like so:
cryptsetup luksFormat --hash sha256 --cipher aes-xts-plain64 --key-size 256 --key-file /certs/luks/array.key /dev/sdb
cryptsetup luksFormat --hash sha256 --cipher aes-xts-plain64 --key-size 256 --key-file /certs/luks/array.key /dev/sdc

/etc/crypttab is as follows, with /dev/sdb and /dev/sdc listed by UUID:
stuff_array1 UUID=4ff49adc-3258-44bd-b46a-81b0098aa437 /certs/luks/array.key luks
stuff_array2 UUID=e8b627d5-1782-49b3-a77c-6549d4f9e189 /certs/luks/array.key luks

/etc/fstab is as follows, with the last line listed by UUIID being the BTRFS filesystem on top of the luks devices:

UUID=de2bc5fa-1bd2-49a9-a871-5a20d55dd053 / btrfs ssd,defaults 0 0
UUID=5167751f-f64f-49db-82c4-3cce50f98e6d /boot ext4 defaults 1 2
UUID=11F1-CA71 /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=356cd014-6fc8-4424-bd31-af16d68b5d1c swap swap defaults 0 0
UUID=3908305d-59ca-4154-98c5-61c73d031c0d /mnt/stuff btrfs defaults 0 0

Note that even when commenting out the line and not mounting on boot, the problem remains. Also, just leaving one device in /etc/crypttab instead of both still causes the problem, regardless of which one it is.

[poettering]

Yeah, we should probably GC .device jobs that are pulled in, but then aren't necessary anymore.

[PhilPotter]

Thanks - I have a custom service file that does it all for the moment with no crypttab present as that seems to work fine.

[poettering]

This is actually a duplicate of #1921