Created attachment 1504091 [details] Boot log with "debug" verbosity Description of problem: First, some background information: I've been using Fedora since Fedora 21, upgrading from one release to the next one without reinstalling. I belong to the more than probable minority of users who boot to a virtual terminal and uses plymouth's text theme. This makes getty@.service critical for me as that's my login prompt. The faster I get that, the better. Now, the problem: After upgrading to Fedora 29 I experienced a noticeable increase in the time it takes for Fedora to show me the login prompt provided by agetty. Previously, it took around 4 seconds from the Grub menu. In Fedora 29, those increased to around 9 (i.e. it takes twice as long!). After plotting the boot process with "systemd-analyze plot", adding "debug" to the kernel command line and taking a look at the boot log as provided by journald, I'm pretty sure the cause is getty@.service declaring the service type to be "idle". In the attached boot log, you can see in line 10268 how systemd is ready to execute agetty and forks creating process 613, immediately declaring the service as started (wall clock time 22:49:57). However, agetty is finally launched in line 11158 (wall clock time 22:50:02) exactly 5 seconds later, which is the timeout for services declared with type "idle". Note that, due to the BIOS clock being in local time, the clock goes back one hour during the boot process so don't let that confuse you. By using "systemctl edit" I created a drop-in snippet in the following location: /etc/systemd/system/getty@.service.d/override.conf And used the following: [Service] Type=simple By doing that, I go back to the login prompt being displayed after just 4 seconds. It's important to notice declaring a service as idle only serves the purpose of making console output prettier by trying to avoid interleaved lines and other processes "trashing" the screen. However, I don't experience any of that. When agetty starts, plymouth goes away and the login prompt is clear. Even if that wasn't the case, notice the idle timeout expires anyway and agetty is launched without the system being idle, defeating the purpose of declaring the unit as type idle. I don't know about other distributions and the way they boot, but I'd argue for Fedora it's better to just use type "simple" for getty@.service. There's still the question of why this started happening after upgrading to Fedora 29, given that in Fedora 28 getty@.service was also "idle" as far as I can see. I don't have an answer for that and I didn't investigate. If you think it's needed, I can provide a (probably blurry) video of my computer booting to showcase the difference between "idle" and "simple" and the lack of text trash in the login screen. Version-Release number of selected component (if applicable): systemd-239-6.git9f3aed1.fc29.x86_64 How reproducible: Always reproducible in my system. Steps to Reproduce: 1. Make multi-user.target the default target. 2. Measure the time to the login prompt. 3. Make getty@.service "simple" instead of "idle" and measure again. Actual results: Time to the login prompt is increased by 5 seconds. Expected results: Time to the login prompt is 5 seconds lower. Additional info:
Created attachment 1504092 [details] Normal boot process with service type "idle"
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Yes, the problem is still present in Fedora 30 exactly as described. I have not upgraded to Fedora 31 yet.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I've just upgraded to Fedora 32 and the problem is still there.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Thank you for the beautiful bug report with a detailed analysis. Apologies for the slow reply. > /etc/systemd/system/getty@.service.d/override.conf > > And used the following: > > [Service] > Type=simple > > By doing that, I go back to the login prompt being displayed after just 4 > seconds. It's important to notice declaring a service as idle only serves the > purpose of making console output prettier by trying to avoid interleaved lines > and other processes "trashing" the screen. However, I don't experience any of > that. When agetty starts, plymouth goes away and the login prompt is clear. Even > if that wasn't the case, notice the idle timeout expires anyway and agetty is > launched without the system being idle, defeating the purpose of declaring the > unit as type idle. Yeah, I think this analysis is correct. Type=idle is a hack: it doesn't guarantee anything, and in various cases it's not really necessary. But I don't think we want to spend time on it, sorry. Text logins are something that is slowly going away. The text console is effectively unmaintained in the kernel, and the best we can hope for is to keep things semi-functional until it's not needed anymore. If setting Type=simple works nicely for you, please keep doing that. But we won't change the default, which is OK for most users.