When unattendedly started via udev, cryptdisks takes 3 minutes to start
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cryptsetup |
New
|
Undecided
|
Unassigned | ||
cryptsetup (Ubuntu) |
Fix Committed
|
Wishlist
|
Unassigned |
Bug Description
Binary package hint: cryptsetup
root@boron# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_
DISTRIB_
DISTRIB_
root@boron# uname -a
Linux boron 2.6.22-14-server #1 SMP Tue Dec 18 05:52:24 UTC 2007 x86_64 GNU/Linux
root@boron# dpkg --status cryptsetup
...
Version: 2:1.0.5-2ubuntu2.1
Some more context might be provided by bug #178829. I modified the
file /lib/cryptsetup
lines 30-35) else cryptsetup does not function at all when called from
udev.
Might be related to bug #162582
This problem occurs on one of two servers set up similary. The udev rule to start
cryptdisks does succeed in creating the "device"
/dev/mapper/
mysterious delay of 3 minutes. The 3 minutes begins on the call to
"cryptdisks restart cryptbak". At the end of the interval, cryptdisks
reports success.
Some details on the setup.
/etc/crypttab
# <target name> <source device> <key file> <options>
cryptbak /dev/bakker /etc/backuppc/
/etc/udev/
KERNEL=="sd?1", ATTRS{serial}
SYMLINK+
/usr/local/
#!/bin/bash
TAG="$(basename $0)"
logger -t "$TAG" "starts..."
logger -t "$TAG" "Looking for bakker: $(ls -l /dev/bakk*)"
invoke-rc.d cryptdisks restart cryptbak
RET=$?
logger -t "$TAG" "cryptdisks returned $RET."
exit 0
/etc/init.
logger -t "cryptdisks" "begins, args: $@"
Example session. On plugging in the external disk, syslog reports:
Jan 28 13:56:27 boron kernel: [ 9178.115246] sdc: sdc1
Jan 28 13:56:27 boron kernel: [ 9178.126109] sd 6:0:0:0: [sdc] Attached SCSI disk
Jan 28 13:56:27 boron kernel: [ 9178.126166] sd 6:0:0:0: Attached scsi generic sg2 type 0
Jan 28 13:56:27 boron cryptbak.sh: starts...
Jan 28 13:56:27 boron cryptbak.sh: Looking for bakker: lrwxrwxrwx 1 root root 4 Jan 28 13:56 /dev/bakker -> sdc1
Jan 28 13:56:27 boron cryptdisks: begins, args: restart cryptbak
At this point, nothing related to cryptdisks is apparently happening. Some things that might be relevent:
root@boron# COLUMNS=200 ps -f $(pgrep -f crypt)
UID PID PPID C STIME TTY STAT TIME CMD
root 4038 2 0 11:24 ? S< 1:05 [kcryptd/0]
root 4039 2 1 11:24 ? S< 2:19 [kcryptd/1]
root 25976 25974 0 13:56 ? S< 0:00 /bin/bash /usr/local/
root 25981 25976 0 13:56 ? S< 0:00 /bin/sh /usr/sbin/
root 25997 25981 0 13:56 ? S< 0:00 /bin/sh /etc/init.
root 26017 25997 0 13:56 ? S< 0:00 /bin/sh /etc/init.
root 26051 26017 1 13:56 ? S<L 0:00 cryptsetup --tries=1 --key-file=
root@boron# ls -l /dev/mapper/
total 0
crw-rw---- 1 root root 10, 63 2008-01-28 11:24 control
brw-rw---- 1 root disk 254, 0 2008-01-28 13:56 temporary-
Finally,
root@boron# Jan 28 13:59:28 boron cryptbak.sh: cryptdisks returned 0.
What was happening between 13:56:27 and 13:59:28?
At this point, all of the process listed above have disappeared except the first two. The contents of /dev/mapper are
root@boron# ls -l /dev/mapper/
total 0
crw-rw---- 1 root root 10, 63 2008-01-28 11:24 control
brw-rw---- 1 root disk 254, 0 2008-01-28 13:59 cryptbak
The 3 minute delay does not occur when the cryptdisks command is given on the command line. E.g.
root@boron# cryptbak.sh
* Stopping remaining crypto disks...
* cryptbak (stopped)...
...done.
* Starting remaining crypto disks...
Jan 28 14:06:58 boron cryptbak.sh: starts...
Jan 28 14:06:58 boron cryptbak.sh: Looking for bakker: lrwxrwxrwx 1 root root 4 2008-01-28 13:56 /dev/bakker -> sdc1
Jan 28 14:06:58 boron cryptdisks: begins, args: restart cryptbak
key slot 0 unlocked.
Command successful.
...done.
root@boron# Jan 28 14:07:00 boron cryptbak.sh: cryptdisks returned 0.
Changed in cryptsetup (Ubuntu): | |
status: | Confirmed → Fix Committed |
I'm confirming this bug for now, because it LOOKS like a genuie bug. However, it is very hard to read and understand. It would have been easier if you had actually attached the files, and not pasted it in the bug description.
Anyway, I currently have the feeling that this bug is actually a feature request, that you halfway implemented, but didn't succeed just before the finishing line. It would be better if this was integrated properly into the cryptsetup package. This would however need the scripts to be written in a more general fashion. Moreover, some maintenance tools for key generation, roll over and general maintance would need to be written, IMO.