Bug 749706

Summary: systemd-cryptsetup ignores timeout parameter of /etc/crypttab
Product: [openSUSE] openSUSE 12.3 Reporter: endym ion <endym>
Component: BasesystemAssignee: systemd maintainers <systemd-maintainers>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: axel.braun, bluedzins, fbui, fcrozat, RBrownCCB, thomas.blume, werner
Version: Final   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE 12.1   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: dmesg with systemd.log_level=debug (systemd lines only)

Description endym ion 2012-02-29 21:38:14 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2

In the openSUSE 12.1 installation I chose to encrypt the whole home partition. When booting the systemd cryptsetup.service ask for the passphrase. If the passphrase is not entered within about 80 seconds, the boot process continues automatically (of course without mounting the home partition) to the user login screen (KDM). This behavior is very annoying because of:
1. an average user will login now and will not see his normal desktop, but a fresh KDE desktop without access to his data
2. if you are not root you have to reboot now

To disable the timeout I added the option "timeout=0" in /etc/crypttab (fourth parameter):
cat /etc/crypttab
cr_sdb3         /dev/disk/by-id/ata-WDC_WD2500BEVS-60UST0_WD-WXE808P0A960-part3 none       timeout=0

But this does not change anything. The timeout is still enabled.

dmesg (after timeout):
systemd[1]: Job dev-mapper-cr_sdb3.device/start timed out.
systemd[1]: Job cryptsetup@cr_sdb3.service/start failed with result 'dependency'.
systemd[1]: Job home.mount/start failed with result 'dependency'.
systemd[1]: Job fsck@dev-mapper-cr_sdb3.service/start failed with result 'dependency'.
systemd[1]: Job dev-mapper-cr_sdb3.device/start failed with result 'timeout'.
systemd-cryptsetup[1882]: Timed out
systemd-cryptsetup[1882]: Failed to query password: Timer expired
systemd[1]: cryptsetup@cr_sdb3.service: main process exited, code=exited, status=1
systemd[1]: Unit cryptsetup@cr_sdb3.service entered failed state.


rpm -q systemd:
systemd-37-3.6.1.x86_64

uname -srvom:
Linux 3.1.9-1.4-desktop #1 SMP PREEMPT Fri Jan 27 08:55:10 UTC 2012 (efb5ff4) x86_64 GNU/Linux


Reproducible: Always

Steps to Reproduce:
1. Encrypt the home partition with the YaST partition manager
2. Add the option "timeout=0" in /etc/crypttab (fourth parameter)
3. Reboot
4. Do not enter the passphrase - wait about 80 seconds
Actual Results:  
Boot process is continued automatically of course without mounting the home partition.

Expected Results:  
systemd waits forever for passphrase entry (boot process stopp)

For additional information see this forum thread: http://forums.opensuse.org/forums/english/get-technical-help-here/install-boot-login/472714-how-disable-timeout-password-entry-encrypted-home-partition.html
Comment 1 Frederic Crozat 2012-03-02 08:56:29 UTC
please boot with systemd.log_level=debug systemd.log_target=kmsg and attach dmesg output after rebooting ?
Comment 2 endym ion 2012-03-02 21:09:05 UTC
Created attachment 479288 [details]
dmesg with systemd.log_level=debug (systemd lines only)
Comment 3 Frederic Crozat 2012-03-05 10:16:58 UTC
confirmed, systemd internal timeout is triggered on the dev-mapper node..
Comment 4 Kun Kun Zhang 2012-03-06 09:42:22 UTC
Hi,could you please look at this? I am not sure whether it is right to assign it to you.Feel free to reassign it whether necessary.Thank you.
Comment 5 Frederic Crozat 2012-04-23 13:57:26 UTC
*** Bug 758081 has been marked as a duplicate of this bug. ***
Comment 6 Axel Braun 2012-06-19 14:55:15 UTC
anything new on this issue?
Comment 7 Frederic Crozat 2012-06-19 15:11:11 UTC
I need to discuss this with upstream
Comment 8 Axel Braun 2013-01-11 14:00:22 UTC
7 month later...and the problem still exists in 12.2
@Frederic: Anything new? Will you change the product 12.1 -> 12.2?
Comment 9 Frederic Crozat 2013-01-11 14:10:38 UTC
I could change the product from 12.1 to 12.2 (or even Factory, although I didn't check if it was fixed), it wouldn't fix the bug :(

I had no time to work on it, timeout is being correctly handled by cryptsetup, but the issue is in the systemd own timeout which is the issue..
Comment 10 Axel Braun 2013-01-11 14:13:41 UTC
(In reply to comment #9)
> I could change the product from 12.1 to 12.2 (or even Factory, although I
> didn't check if it was fixed), it wouldn't fix the bug :(

Just asking because some bug owner like to keep it in the version the bug originally was detected. For regression tests.

> I had no time to work on it, timeout is being correctly handled by cryptsetup,
> but the issue is in the systemd own timeout which is the issue..

Any workaround so far?
Comment 11 Frederic Crozat 2013-01-11 14:18:15 UTC
(In reply to comment #10)

> > I had no time to work on it, timeout is being correctly handled by cryptsetup,
> > but the issue is in the systemd own timeout which is the issue..
> 
> Any workaround so far?

Unfortunately, no, current code is already setting "TimeoutSec=0" in the generated .service which is supposed to ensure timeout is correctly handled but other unit is timeouting (the one for the device, IIRC)
Comment 12 endym ion 2013-01-13 17:42:07 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > I could change the product from 12.1 to 12.2 (or even Factory, although I
> > didn't check if it was fixed), it wouldn't fix the bug :(
> 
> Just asking because some bug owner like to keep it in the version the bug
> originally was detected. For regression tests.
> 
> > I had no time to work on it, timeout is being correctly handled by cryptsetup,
> > but the issue is in the systemd own timeout which is the issue..
> 
> Any workaround so far?

Hi Axel,

you will find a workaraound in the forum thread I mentioned at the end of the bug report.

endym
Comment 13 Frederic Crozat 2013-04-03 14:42:54 UTC
Upstream has just got a patch submission to fix this. I'll test it as soon as it is accepted.
Comment 14 Frederic Crozat 2013-06-18 01:30:06 UTC
*** Bug 823823 has been marked as a duplicate of this bug. ***
Comment 15 macias - 2013-06-18 05:07:16 UTC
For the record, the workaround given on forum worked until OS 12.3 (i.e. in OS 12.3 the trick no longer works).
Comment 16 Ludwig Nussel 2013-07-02 15:05:07 UTC
*** Bug 823802 has been marked as a duplicate of this bug. ***
Comment 17 Ludwig Nussel 2013-07-02 15:05:58 UTC
Shouldn't we better move the bug to 12.3?
Comment 18 Frederic Crozat 2013-07-02 15:20:52 UTC
yes.. I've tested a patch from upstream (it is supposed to be fixed in Factory already) but it doesn't seem to work as expected. I need to debug this further..
Comment 19 Axel Braun 2013-10-28 08:11:56 UTC
As this does not work for systemd 195 (openSUSE 12.3), I assume it affects 13.1 as well?
Comment 20 Frederic Crozat 2013-10-29 17:57:41 UTC
no, as noted in my comment 18, it should be fixed in 13.1
Comment 21 Dr. Werner Fink 2014-01-15 11:37:29 UTC
(In reply to comment #20)
> no, as noted in my comment 18, it should be fixed in 13.1

Is it possible to apply the patch to systemd 195?
Comment 22 Franck Bui 2015-06-25 15:11:49 UTC
Work as expected on opensuse 13.1 so I'm tempted to close this one.
Comment 23 Thomas Blume 2015-09-18 13:10:32 UTC
(In reply to Franck Bui from comment #22)
> Work as expected on opensuse 13.1 so I'm tempted to close this one.

And it is fixed in newer versions, see bug 909912.
Closing as fixed in current version.