Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1885488 - Several services take too long to start
Summary: Several services take too long to start
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 33
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-06 06:25 UTC by Saurav Sengupta
Modified: 2020-10-06 08:04 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: ---
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
Output of systemd-analyze blame (dnf-makecache.service can be ignored) (8.13 KB, text/plain)
2020-10-06 06:25 UTC, Saurav Sengupta
no flags Details
Second cold boot output of systemd-analyze blame (7.86 KB, text/plain)
2020-10-06 08:04 UTC, Saurav Sengupta
no flags Details

Description Saurav Sengupta 2020-10-06 06:25:04 UTC
Created attachment 1719263 [details]
Output of systemd-analyze blame (dnf-makecache.service can be ignored)

Created attachment 1719263 [details]
Output of systemd-analyze blame (dnf-makecache.service can be ignored)

Description of problem:
Several services starting at boot time take too long to start. These include dracut-initqueue, firewalld, upower, sssd, etc.

Version-Release number of selected component (if applicable):
systemd.x86 - 246.6-3.fc33
Service provider version numbers are the latest as on 6 Oct 2020 (IST).

How reproducible:
Always

Steps to Reproduce:
1. Do a cold boot.
2. Check the output of systemd-analyze blame

Actual results:
The topmost services take too long (more than ~ 5-6 secs) to start. firewalld.service blocks for about 6-7 secs. If it is disabled, upower takes about the same time. This adds about 7 seconds to the boot time (see systemd-analyze critical-chain - the blocking approximately doubles the start-up time). A warm (re)boot takes even longer.

Expected results:
Critical system services should not take so long to start, blocking and increasing the start-up time.

Additional info:
The system has LUKS2-encrypted partitions with manual password entry, which is why cryptsetup takes long, but that is reasonable and acceptable. lvm, lvmmerge, iscsi, multipath, mdraid, md, dmraid, qemu, qemu-net, virtfs, livesys, and livesys-late are disabled in the GRUB configuration (disabling these in the dracut configuration makes no difference). Related systemd services are also disabled/masked. plymouth-quit-wait is also masked (enabling it makes the start-up time even longer). /var/log/journal/ has been deleted so that the journal is created on tmpfs /run/log/journal/ .

Comment 1 Saurav Sengupta 2020-10-06 06:28:17 UTC
The affected system is Fedora Workstation 33 Pre-release Edition (33 Beta), running the default GNOME 3.38 desktop environment.

Comment 2 Saurav Sengupta 2020-10-06 08:04:49 UTC
Created attachment 1719300 [details]
Second cold boot output of systemd-analyze blame

Attached another (usual case) output of systemd-analyze blame . It can be seen that dracut-initqueue, firewalld, upower, and sssd are taking a significant amount of time. I know that these do run in parallel, but any one of them blocking adds that time period to the start-up time, which is my primary concern here. Also, e.g., if I disable firewalld, upower will block in its place.


Note You need to log in before you can comment on or make changes to this bug.