[systemd-devel] hinting systemd about what to do to make a device appear

[Lennart Poettering]

On Thu, 10.09.15 12:00, martin f krafft (madduck at madduck.net) wrote:

> Hi,
> 
> on one of my machines, /srv/backup is an encrypted filesystem
> sitting on top of a DRBD volume. In /etc/crypttab, I thus have
> 
>   backup /dev/drbd/by-res/backup none noauto
> 
> and then I mount /dev/mapper/backup on /srv/backuppc.
> 
> systemd-cryptsetup-generated creates a unit for this which includes
> the following lines:
> 
>   BindsTo=dev-drbd-by\x2dres-backup.device
>   After=dev-drbd-by\x2dres-backup.device
> 
> But this device is unknown to systemd, which was informed by udev
> only about sys-devices-virtual-block-drbd0.device.
> /dev/drbd/by-res/backup is indeed a symlink to /dev/drbd0, but for
> obvious reasons, I prefer using the named path, rather than the
> arbitrary /dev/drbd0 name (which has in the past been /dev/drbd1
> under certain circumstances).
> 
> So when I attempt to start the cryptsetup-volume:
> 
>   # systemctl start systemd-cryptsetup at backup.service
> 
> it times out waiting for dev-drbd-by\x2dres-backup.device, even
> though the file in /dev (and DRBD) are ready to go.
> 
> Can I somehow give systemd the missing information, namely that in
> order to provide this device, it needs to start drbd.service, or if
> drbd.service is running, then the device can be assumed to exist?
> 
> Or what else would you suggest?

Does udev know about the symlink? I.e. does "udevadm info" show it?
Which component is creating it? Only symlinks created by udev are
known by udev and systemd. To support this, the drbd support needs to
install rules files that create them, and not touch /dev directly. In
fact, nothing ever should touch /dev directly, except for udev.

Lennart

-- 
Lennart Poettering, Red Hat