Bug 451241 - cryptsetup is 100 times slower then in f8
cryptsetup is 100 times slower then in f8
Product: Fedora
Classification: Fedora
Component: cryptsetup-luks (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-06-13 12:11 EDT by Levente Farkas
Modified: 2008-08-25 11:34 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-08-25 11:34:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
10-local.rules (341 bytes, text/plain)
2008-06-16 18:19 EDT, Levente Farkas
no flags Details
home-up (427 bytes, text/plain)
2008-06-16 18:25 EDT, Levente Farkas
no flags Details
luks-up (616 bytes, text/plain)
2008-06-16 18:26 EDT, Levente Farkas
no flags Details
Bootchart of stalled cryptsetup/udevsettle (272.49 KB, image/png)
2008-07-13 04:55 EDT, Martin Blom
no flags Details

  None (edit)
Description Levente Farkas 2008-06-13 12:11:44 EDT
Description of problem:
my home directory is a luks encrypted volume. the key for this volume is on my
pendrive. before i'd like to login i just plug my pendrive and it then:
- udev recognize my pendrive
- mount one of the partition on it (which hold the keyfile)
- use the keyfile on the mounted partition and open the luks partirion
- mount the device mapper as my home
- umount my pendrive
this was works perfectly on fedora 8 and takes about 2-4sec to my home dir be
now on fedora 9 it's still works, but it takes about 3-4 minutes (!!!) to
finish. when i look into what happened:
- udev recognize my pendrive
- mount one of the partition on it (which hold the keyfile)
- use the keyfile on the mounted partition and open the luks partirion
and here waits for minutes in this place what is see in ps axf:
  522 ?        S<s    0:00 /sbin/udevd -d
 2523 ?        S<     0:00  \_ /sbin/udevd -d
 2536 ?        S<     0:00      \_ /bin/bash /root/bin/home-up /dev/System/lfarkas
 2553 ?        S<     0:00          \_ /bin/bash /root/bin/luks-up
 2569 ?        S<L    0:00              \_ /sbin/cryptsetup luksOpen
/dev/System/lfarkas home-lfarkas
 2718 ?        S<     0:00                  \_ /sbin/udevsettle
i assume udevsettle what for something, but i don't know for what?
and why?
whould you like to see all of my scripts?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Till Maas 2008-06-16 17:38:37 EDT
Can you please run cryptsetup luksOpen manually and report whether it also takes
that long?

Also, please remove the lines from the bug report template that you do not use
in future bug reports, otherwise half of my screen is filled with useless space.
Please also always report the version-release number, i.e. here the output of
rpm --qf '%{name}-%{version}-%{release}\n' -q cryptsetup-luks udev
Comment 2 Levente Farkas 2008-06-16 18:17:53 EDT
fully updated f9:
and when i run it manually it doesn't takes so long...
so it seems there are some 'interference' between the event i plugin my pendrive
and luksOpen's call of udevsettle.
the most annoying thing that it was working in f7 and f8 like a charm:-(((
Comment 3 Levente Farkas 2008-06-16 18:18:54 EDT
if it's help i can attach the scripts
Comment 4 Levente Farkas 2008-06-16 18:19:53 EDT
Created attachment 309544 [details]
Comment 5 Levente Farkas 2008-06-16 18:25:24 EDT
Created attachment 309546 [details]
Comment 6 Levente Farkas 2008-06-16 18:26:13 EDT
Created attachment 309547 [details]
Comment 7 Till Maas 2008-06-16 18:32:30 EDT
I am pretty sure that the bug here is that udevsettle waits for cryptsetup to
complete its task and therefore it waits 180 seconds, which is the default
timeout. And cryptsetup waits for udevsettle, so there is a typical deadlock. I
just read on the upstream mailing list, that calling udevsettle was introduced
into cryptsetup recently, therefore this did not happen in earlier releases of
Comment 8 Till Maas 2008-06-16 18:57:05 EDT
Maybe it helps when you run the home-up script with nohup in the udev rule, i.e.
change RUN+="/root/bin/home-up /dev/System/lfarkas" but this may be a stupid
idea. ;-)
Comment 9 Levente Farkas 2008-06-18 06:11:59 EDT
what kind of info needed for you? i see you set the status to "NEEDINFO
requested from lfarkas@lfarkas.org" but not requested any kind of info:-(
Comment 10 Till Maas 2008-06-18 06:40:10 EDT
(In reply to comment #9)
> what kind of info needed for you? i see you set the status to "NEEDINFO
> requested from lfarkas@lfarkas.org" but not requested any kind of info:-(

Please try nohup in your udev rule:
RUN+="/usr/bin/nohup /root/bin/home-up /dev/System/lfarkas"
RUN+="/root/bin/home-up /dev/System/lfarkas&"
or in case this does not work, create a wrapper script that runs home-up in the
background (with & attached). But I am not sure whether or not this will break
something, because I am not an expert in writing udev rules.
Comment 11 Levente Farkas 2008-06-18 09:57:53 EDT
imho it's not a solution. it's a deadlock which shouldn't have to happend.
anyway nohup don't put the process in the background:-) and & not working in
RUN. of course i can workaround this in my scripts (as i already did it), but
this should have to be solved in an other way.
Comment 12 Milan Broz 2008-06-19 11:45:16 EDT
In upstream cryptsetup svn is patch which decrease udev settle timeout, maybe
for short term fix it is enough.

Anyway, I think that calling udevsettle directly from cryptsetup is not good idea.

Better is somehow tell udev to not touch "temporary-cryptsetup-*" mapper
devices, then udevsettle call is not needed IHMO.
Comment 13 Levente Farkas 2008-06-19 17:21:53 EDT
does this means next cryptsetup on fedora won't call udevsettle?
and where did you find cryptsetup svn??? anyway in my case  any kind of short
timeout is too long:-(
Comment 14 Martin Blom 2008-07-13 04:53:45 EDT
I think I have the same problem, only my encrypted partition is actually a HD
partition one which I have local user's home directories.

On bootup, I'm asked for password for /dev/sda8. Once entered, it takes serveral
minutes until the "unlocked" message appears, and the again serveral minutes
until the boot process proceeds!

Meaning, my laptop takes 410 seconds to boot. :-(

In F8, everything worked perfectly. This is a fresh F9 install (since upgrading
F8->F9 messed up the system badly).
Comment 15 Martin Blom 2008-07-13 04:55:18 EDT
Created attachment 311659 [details]
Bootchart of stalled cryptsetup/udevsettle

Here is my boot sequence in F9. I entered the password as soon as the prompt
Comment 16 Martin Blom 2008-07-21 14:44:56 EDT
No progress on this one?

I've binary patched /lib64/libcryptsetup.so.0.0.0 to execute /bin/true instead
of /sbin/udevsettle and thereby cut my boot time with 6 minutes, but that
doesn't feel quite right ...
Comment 17 Levente Farkas 2008-07-22 04:49:23 EDT
i simple rewrite my rules to workaround this problem since udev and cryptsetup
people thing the current behavior is right:-(

Note You need to log in before you can comment on or make changes to this bug.