When unattendedly started via udev, cryptdisks takes 3 minutes to start

Bug #186835 reported by KM
10
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_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"
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/cryptdisks.functions accordingly (i.e. removing
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/cryptbak. Unfortunately it does so only after a
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/diskparm.txt luks,loud,tries=1

/etc/udev/rules.d/50-nick.rules
   KERNEL=="sd?1", ATTRS{serial}=="DEF10BBE1D0D", NAME="$kernel", \
      SYMLINK+="bakker", RUN+="/usr/local/sbin/cryptbak.sh"

/usr/local/sbin/cryptbak.sh

   #!/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.d/cryptdisks has this line added just after the "set -e":
   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/sbin/cryptbak.sh
   root 25981 25976 0 13:56 ? S< 0:00 /bin/sh /usr/sbin/invoke-rc.d cryptdisks restart cryptbak
   root 25997 25981 0 13:56 ? S< 0:00 /bin/sh /etc/init.d/cryptdisks restart cryptbak
   root 26017 25997 0 13:56 ? S< 0:00 /bin/sh /etc/init.d/cryptdisks restart cryptbak
   root 26051 26017 1 13:56 ? S<L 0:00 cryptsetup --tries=1 --key-file=/etc/backuppc/diskparm.txt luksOpen /dev/bakker cryptbak

   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-cryptsetup-26051

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.

Revision history for this message
Reinhard Tartler (siretart) wrote :

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.

Changed in cryptsetup:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Reinhard Tartler (siretart) wrote :

duplicate bug #191759 is probably easier to read and understand. plus it a seperate script called gno-crypt is presented there as an alternative to running crypdisks

Revision history for this message
Reinhard Tartler (siretart) wrote :
Changed in cryptsetup (Ubuntu):
status: Confirmed → Fix Committed
Revision history for this message
Mark (markthecodehamster) wrote :

10 years old issue, time to close this?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.