Bug 682166

Summary: /dev/.systemd/ask-password prevents services from starting ?
Product: [Fedora] Fedora Reporter: Jóhann B. Guðmundsson <johannbg>
Component: systemdAssignee: systemd-maint
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: johannbg, johannbg, lpoetter, metherid, mschmidt, notting, plautrba, skr
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-25 18:19:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Dmesg output
none
Systemd dump
none
Systemd test
none
The new and improved version of firstboot-graphical.service :)
none
Strace output from firstboot-graphical service starting none

Description Jóhann B. Guðmundsson 2011-03-04 10:51:31 UTC
Created attachment 482267 [details]
Dmesg output

Description of problem:

I was looking into fixing firstboot services when I hit this while testing firstboot-graphical.service as in the service start seem to hang on /dev/.systemd/ask-password I also saw ntp service hang due to a similar issue unfortunetly I forgot to add the strace ouput to a file when I was looking at it so I'm going by memory here since ntpd fixed it self so we might be hitting race conditions with systemd/plymouth ask password service? 

Note that the test machine has no encrypted partitions.

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

systemd-19-1.fc15

How reproducible:

Happens always when starting firstboot-graphical.service and perhaps other random services 

Steps to Reproduce:
1. replaces the current firstboot service with the new and improve version :)
2.
3.
  
Actual results:

Systemd ask-passsword prevents the service from starting 

Expected results:

Firstboot to start

Additional info:

Comment 1 Jóhann B. Guðmundsson 2011-03-04 10:52:31 UTC
Created attachment 482268 [details]
Systemd dump

Comment 2 Jóhann B. Guðmundsson 2011-03-04 10:53:12 UTC
Created attachment 482269 [details]
Systemd test

Comment 3 Jóhann B. Guðmundsson 2011-03-04 10:54:10 UTC
Created attachment 482270 [details]
The new and improved version of firstboot-graphical.service :)

Comment 4 Jóhann B. Guðmundsson 2011-03-04 10:55:00 UTC
Created attachment 482271 [details]
Strace output from firstboot-graphical service starting

Comment 5 Lennart Poettering 2011-03-04 12:49:40 UTC
Hmm, what exactly is this bug about? I don't follow? What isn't happening that you expected to happen and what happens what you aren't expecting to happen? 

What is the change in the firstboot-graphical.service file you attached?

(In that service file the ExecStartPost= lines need to refer to absolute path names. systemd does not accept relative paths, and will no look for these programs in $PATH. This is actually explicitly warned about in dmesg.)

Comment 6 Jóhann B. Guðmundsson 2011-03-04 13:47:38 UTC
(In reply to comment #5)
> Hmm, what exactly is this bug about? I don't follow? What isn't happening that
> you expected to happen and what happens what you aren't expecting to happen? 
> 

This is about there is something preventing a service from being started. ( saw similar thing on RC2 testing where ntp service just hanged ) 

Did you look at the attached strace output in it the service actually never get started it just hangs there until I break out of it? 

For instance why is "systemd-tty-ask-password-agent" being called when I as a logged in root user when I start the service firsboot-graphical services?

1434  execve("/bin/systemd-tty-ask-password-agent", ["/bin/systemd-tty-ask-password-ag"..., "--watch"], [/* 20 vars */]) = 0 <--- ? 

> What is the change in the firstboot-graphical.service file you attached?

# diff firstboot-graphical.service firstboot-graphical.service.org 
8c8
< Type=oneshot
---
> Environment=RUNLEVEL=5
10,12c10
< ExecStart=/usr/sbin/firstboot
< ExecStartPost=/bin/systemctl disable firstboot-graphical.service
< ExecStartPost=/bin/systemctl disable firstboot-text.service
---
> ExecStart=/etc/init.d/firstboot start
16c14
< 
---
> Type=oneshot

> (In that service file the ExecStartPost= lines need to refer to absolute path
> names. systemd does not accept relative paths, and will no look for these
> programs in $PATH. This is actually explicitly warned about in dmesg.)

Noted and FIXED =)

Comment 7 Lennart Poettering 2011-04-06 01:52:46 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Hmm, what exactly is this bug about? I don't follow? What isn't happening that
> > you expected to happen and what happens what you aren't expecting to happen? 
> > 
> 
> This is about there is something preventing a service from being started. ( saw
> similar thing on RC2 testing where ntp service just hanged ) 
> 
> Did you look at the attached strace output in it the service actually never get
> started it just hangs there until I break out of it? 
> 
> For instance why is "systemd-tty-ask-password-agent" being called when I as a
> logged in root user when I start the service firsboot-graphical services?
> 
> 1434  execve("/bin/systemd-tty-ask-password-agent",
> ["/bin/systemd-tty-ask-password-ag"..., "--watch"], [/* 20 vars */]) = 0 <--- 

When systemctl is run on a tty we spawn off a tty password agent temporarily to deal with password prompts. It is automatically terminated when systemctl ends. You can turn this off with --no-ask-password. Why do we do this? Think you start apache, which needs a passphrase for a SSL certificate to start up, so we need to prompt you, so that "systemctl start" doesn't hang there for good. Or think even further: apache pulls in a crypto disk in some way, now we need to as for that passphrase too.

So, is there anything left open to fix here?

Comment 8 Sebastian Krämer 2011-05-29 10:29:34 UTC
I'm not sure if this is the place to ask this question but: The password prompt for luks-encrypted devices appears to block all other scripts while it would be nice to have other services start up in the background.
Obviously there's a difference betwekk graphical/plymouth boot and text-only boot where start of other services would mess up the input prompt.

Anyway, tty-ask-password does block other services but maybe it wouldn't always need to?

Comment 9 Fedora Admin XMLRPC Client 2011-10-20 16:26:41 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Jóhann B. Guðmundsson 2012-01-25 18:19:24 UTC
Hum needinfo on me hehe closing this nothing left to fix here =) 

Sebastian please open a different bug since your issue is not the same as this if you are still experiencing your issue thanks...