[dm-crypt] Long Unlocking Time

[dm-crypt] Long Unlocking Time

[Ali Reza Sajedi]

Hello all,

I have an encrypted USB drive which I would like to be unlocked and mounted 
when it is attached to the system.

For this purpose I have a perl script called via a dev-rule when the drive 
is attached.

In the script I call the following comand to open the drive:

system ("cryptsetup luksOpen /dev/sdb1 sdb1 --key-file 
/path-to-keyfile/keyfile");

and the following command to mount it on a predefined mountpoint:

system ("mount -o sync,dirsync /dev/mapper/sdb1 /mnt/usb");

Everything works except that the unlocking process takes about 3 minutes.

If I call the script via command shell the unlocking process is executed 
instantly.

Does anyone has a clue as to what the reason for this strange behaviour 
could be?

I would be grateful for any hint in this regard.

Best regards

Ali 

Re: [dm-crypt] Long Unlocking Time

[Bryan Kadzban]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

Ali Reza Sajedi wrote:
> Hello all,
> 
> I have an encrypted USB drive which I would like to be unlocked and 
> mounted when it is attached to the system.
> 
> For this purpose I have a perl script called via a dev-rule when the 
> drive is attached.
> 
> In the script I call the following comand to open the drive:
> 
> system ("cryptsetup luksOpen /dev/sdb1 sdb1 --key-file 
> /path-to-keyfile/keyfile");

Udev is probably the wrong place to do this, since cryptsetup does some
udev magic to make it wait for all outstanding events.

And guess what: your script that ran from udev, that called cryptsetup,
is making one of those events stay outstanding.  :-)

You might be able to change the rule, making it call your script
differently, but what I'd try is either (a) finding somewhere else to
hook this script in (not that I have any good suggestions :-( ), or (b)
trying to make the script fork and do the work in the background.

> and the following command to mount it on a predefined mountpoint:
> 
> system ("mount -o sync,dirsync /dev/mapper/sdb1 /mnt/usb");

Doesn't your desktop handle automount for you when the /dev/mapper/*
device shows up?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [dm-crypt] Long Unlocking Time

[Milan Broz]

On 03/25/2010 04:56 PM, Ali Reza Sajedi wrote:
> For this purpose I have a perl script called via a dev-rule when the drive 
> is attached.

If it is cryptsetup 1.0.6 it internally calls udevadm settle, you
are running from udev rule, so it waits for itself ->deadlock -> timeout.

I later version is this removed, BUT:
If you are using device-mapper with udev enabled, its need to synchronise
device node creation, which happens from the last dm udev-rule, but you are blocked
in rule before -> deadlock -> timeout (maybe).

Best do not do these operations from udev rule at all.

Maybe if it fork itself, it can work somehow. Anyway it is probably better
to not add such commands directly to udev rule, but in some other system
which registers for udev events (using some d-bus message or whatever).

Someone probably can suggest better desktop solution...

Milan

Re: [dm-crypt] Long Unlocking Time

[Thomas Bächler]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

Am 25.03.2010 17:22, schrieb Milan Broz:
> I later version is this removed, BUT:
> If you are using device-mapper with udev enabled, its need to synchronise
> device node creation, which happens from the last dm udev-rule, but you are blocked
> in rule before -> deadlock -> timeout (maybe).

Does cryptsetup even use this synchronization feature?

> Best do not do these operations from udev rule at all.
> 
> Maybe if it fork itself, it can work somehow. Anyway it is probably better
> to not add such commands directly to udev rule, but in some other system
> which registers for udev events (using some d-bus message or whatever).
> 
> Someone probably can suggest better desktop solution...

One does not always want to rely on a desktop-based solution.

It should be possible to run a command that immediately daemonizes and
returns success. In fact, udev should probably implement a RUNAFTER
directive that does exactly that and can be used instead of the RUN
directive.
In my opinion, udev is the right place for such tasks, unless you want
to use or even write a daemon that listens for events using libudev -
which is overkill for such an easy task.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [dm-crypt] Long Unlocking Time

[Milan Broz]

On 03/25/2010 06:10 PM, Thomas Bächler wrote:
> Am 25.03.2010 17:22, schrieb Milan Broz:
> In my opinion, udev is the right place for such tasks, unless you want
> to use or even write a daemon that listens for events using libudev -
> which is overkill for such an easy task.

Udev rules should maintain /dev, not run time expensive operation which
will block all following events for the device.

Anyway, all I want to say is:
with cryptsetup 1.0.6 it will deadlocks because of internal "udevadm settle",
and this is what you are probably seeing. You cat try update if you have this version.

Milan

Re: [dm-crypt] Long Unlocking Time

[Ali Reza Sajedi]

Dear all,

Thank you very much for your help sofar.

The version I am using is 1.0.6, and as Milan pointed out, this version has 
this behaviour.

Before doing anything else I will upgrade to see if this helps.

Ali

----- Original Message ----- 
From: "Milan Broz" <mbroz@redhat.com>
To: "Thomas Bächler" <thomas@archlinux.org>
Cc: <dm-crypt@saout.de>; "Ali Reza Sajedi" <arsajedi@khanehjou.com>
Sent: Thursday, March 25, 2010 6:28 PM
Subject: Re: [dm-crypt] Long Unlocking Time


On 03/25/2010 06:10 PM, Thomas Bächler wrote:
> Am 25.03.2010 17:22, schrieb Milan Broz:
> In my opinion, udev is the right place for such tasks, unless you want
> to use or even write a daemon that listens for events using libudev -
> which is overkill for such an easy task.

Udev rules should maintain /dev, not run time expensive operation which
will block all following events for the device.

Anyway, all I want to say is:
with cryptsetup 1.0.6 it will deadlocks because of internal "udevadm 
settle",
and this is what you are probably seeing. You cat try update if you have 
this version.

Milan
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt 

Re: [dm-crypt] Long Unlocking Time

[Ali Reza Sajedi]

Dear all,

upgrading to 1.1.0 solved the problem.

Thanks to all of you.

Best regards

Ali

----- Original Message ----- 
From: "Milan Broz" <mbroz@redhat.com>
To: "Thomas Bächler" <thomas@archlinux.org>
Cc: <dm-crypt@saout.de>; "Ali Reza Sajedi" <arsajedi@khanehjou.com>
Sent: Thursday, March 25, 2010 6:28 PM
Subject: Re: [dm-crypt] Long Unlocking Time


On 03/25/2010 06:10 PM, Thomas Bächler wrote:
> Am 25.03.2010 17:22, schrieb Milan Broz:
> In my opinion, udev is the right place for such tasks, unless you want
> to use or even write a daemon that listens for events using libudev -
> which is overkill for such an easy task.

Udev rules should maintain /dev, not run time expensive operation which
will block all following events for the device.

Anyway, all I want to say is:
with cryptsetup 1.0.6 it will deadlocks because of internal "udevadm 
settle",
and this is what you are probably seeing. You cat try update if you have 
this version.

Milan
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt 

[dm-crypt] Change Language

[Ali Reza Sajedi]

Hello,

How could I change cryptsetup language shown at the prompt line?

Previously used to be english with version 1.0.6. But after upgrading to 
1.1.0 is german now.

I want to have it set back to english again.

Best regards

Ali 

Re: [dm-crypt] Change Language

[Sven Eschenberg]

Setup your locale properly maybe?

For me cryptsetup outputs the language I chose as system locale.

Regards

-Sven

On Sat, March 27, 2010 12:09, Ali Reza Sajedi wrote:
> Hello,
>
> How could I change cryptsetup language shown at the prompt line?
>
> Previously used to be english with version 1.0.6. But after upgrading to
> 1.1.0 is german now.
>
> I want to have it set back to english again.
>
> Best regards
>
> Ali
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Change Language

[Ali Reza Sajedi]

Thank you, Sven

Setting locale was the right option.

Best regards

Ali

----- Original Message ----- 
From: "Sven Eschenberg" <sven@whgl.uni-frankfurt.de>
To: <dm-crypt@saout.de>
Sent: Saturday, March 27, 2010 1:45 PM
Subject: Re: [dm-crypt] Change Language


> Setup your locale properly maybe?
> 
> For me cryptsetup outputs the language I chose as system locale.
> 
> Regards
> 
> -Sven
> 
> On Sat, March 27, 2010 12:09, Ali Reza Sajedi wrote:
>> Hello,
>>
>> How could I change cryptsetup language shown at the prompt line?
>>
>> Previously used to be english with version 1.0.6. But after upgrading to
>> 1.1.0 is german now.
>>
>> I want to have it set back to english again.
>>
>> Best regards
>>
>> Ali
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] Long Unlocking Time

[Sven Eschenberg]

Milan Broz schrieb:
> On 03/25/2010 04:56 PM, Ali Reza Sajedi wrote:
>> For this purpose I have a perl script called via a dev-rule when the drive 
>> is attached.
> 
> If it is cryptsetup 1.0.6 it internally calls udevadm settle, you
> are running from udev rule, so it waits for itself ->deadlock -> timeout.

That is indeed true, since calling udevadm was a really bad hack, it 
does wait for complete settlement, which of course yields a race 
condition ending up with a dealock.

> 
> I later version is this removed, BUT:
> If you are using device-mapper with udev enabled, its need to synchronise
> device node creation, which happens from the last dm udev-rule, but you are blocked
> in rule before -> deadlock -> timeout (maybe).

It's a little bit more complicated, I think. If udev would care for 
ordering of events, doing them synchronously, you would probably be 
right, then again, you would not need any synchronization to avoid a 
race condition. (Imho it is a blatant maldesign that uevent does not 
provide real event based programming and an apropriate API, but that's a 
different story).
Usually what I would expect to happen: usb device is added - uevent is 
created, udev calls cryptsetup during processing of uevent, crypsetup 
does dm setup and waits for completion of inode creation - is this done 
via an IOCTL? During this process more uevents are created. Since there 
is no synchronization the new uevent is passed down to udevd and the 
apropriate action is taken (i.e. create symbolic name, whatsoever). 
cryptsetup can terminate and thus processing of the previously generated 
uevent finishes.
This is even true when you do not use udev, since for any uevent 
/sys/proc/hotplug when set is executed at the time it occurs. There is 
neither ordering nor any synchronization.

> 
> Best do not do these operations from udev rule at all.
> 
> Maybe if it fork itself, it can work somehow. Anyway it is probably better
> to not add such commands directly to udev rule, but in some other system
> which registers for udev events (using some d-bus message or whatever).
> 
> Someone probably can suggest better desktop solution...
> 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Well, wasn't it exactly meant to be a hotplug processor in the first 
place, not only a flexible inode name generator?

Just my 2 cent.

-Sven

P.S. To the original poster: Use an up to date version of cryptsetup. 
Monitor uevents and their processing whilst plugging your harddisk, if 
you still have a deadlock problem, this might help finding out why.