Hide Forgot
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:
Created attachment 482268 [details] Systemd dump
Created attachment 482269 [details] Systemd test
Created attachment 482270 [details] The new and improved version of firstboot-graphical.service :)
Created attachment 482271 [details] Strace output from firstboot-graphical service starting
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.)
(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 =)
(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?
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?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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...