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:
And used the following:
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):
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.
Time to the login prompt is increased by 5 seconds.
Time to the login prompt is 5 seconds lower.
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.