init is using 100% of processor

Bug #1890913 reported by Danial Behzadi on 2020-08-08
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Undecided
Unassigned
systemd (Ubuntu)
Undecided
Unassigned

Bug Description

the `sbin/init splash` process is using more than 100% of processor after boot.

ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: systemd 246-2ubuntu1
ProcVersionSignature: Ubuntu 5.8.0-12.13-generic 5.8.0-rc7
Uname: Linux 5.8.0-12-generic x86_64
ApportVersion: 2.20.11-0ubuntu44
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted
Date: Sat Aug 8 22:14:37 2020
InstallationDate: Installed on 2019-11-01 (280 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
MachineType: LENOVO 2349KEG
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-12-generic root=/dev/mapper/vgubuntu-root ro i915.fastboot=1 quiet splash vt.handoff=7
SourcePackage: systemd
SystemdDelta:
 [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf
 [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf

 2 overridden configuration files found.
SystemdFailedUnits:
 Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?).
 Unit \xe2\x97\x8f.service could not be found.
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/07/2019
dmi.bios.release: 2.82
dmi.bios.vendor: LENOVO
dmi.bios.version: G1ETC2WW (2.82 )
dmi.board.asset.tag: Not Available
dmi.board.name: 2349KEG
dmi.board.vendor: LENOVO
dmi.board.version: Win8 Pro DPK TPG
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.ec.firmware.release: 1.14
dmi.modalias: dmi:bvnLENOVO:bvrG1ETC2WW(2.82):bd08/07/2019:br2.82:efr1.14:svnLENOVO:pn2349KEG:pvrThinkPadT430:rvnLENOVO:rn2349KEG:rvrWin8ProDPKTPG:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.family: ThinkPad T430
dmi.product.name: 2349KEG
dmi.product.sku: LENOVO_MT_2349
dmi.product.version: ThinkPad T430
dmi.sys.vendor: LENOVO
modified.conffile..etc.default.apport:
 # set this to 0 to disable apport, or to 1 to enable it
 # you can temporarily override this with
 # sudo service apport start force_start=1
 enabled=0
mtime.conffile..etc.default.apport: 2020-08-08T22:11:41.151132

Danial Behzadi (dani.behzi) wrote :
Danial Behzadi (dani.behzi) wrote :

Here is a screenshot of htop.

Balint Reczey (rbalint) on 2020-08-08
tags: added: block-proposed
Changed in systemd (Ubuntu):
importance: Undecided → High
Balint Reczey (rbalint) wrote :

Fastboot is known to cause issues on older CPUs:
https://wiki.archlinux.org/index.php/intel_graphics#Fastboot

If the i915.fastboot=1 option was _not_ set by you manually then please reopen the bug by settint status to New.

Changed in systemd (Ubuntu):
importance: High → Undecided
status: New → Incomplete
affects: systemd (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Incomplete → Invalid
tags: removed: block-proposed
Danial Behzadi (dani.behzi) wrote :

1. It was not set by me manually
2. After removing the corresponding line from `/etc/default/grub` and updating grub and initramfs, the problem is still there.

Changed in linux (Ubuntu):
status: Invalid → New

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1890913

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Danial Behzadi (dani.behzi) wrote :

1. It was not set by me manually
2. After removing the corresponding line from `/etc/default/grub` and updating grub and initramfs, the problem is still there.

Balint Reczey (rbalint) wrote :

Systemd since then migrated and probably we don't want to have the kernel migrated as well to trigger the issue, thus I've added the block-proposed tag.

tags: added: block-proposed
Seth Forshee (sforshee) wrote :

I hadn't seen this bug before today when I noticed that it's blocking my kernel in groovy-proposed. I upgraded systemd, and I am seeing this issue. But when I boot back to 5.4.0-37 the problem persists, so it doesn't seem to have anything to do with the 5.8 kernel.

It seems like a problem with apport-autoreport.service. I'm not an expert on debugging system units, but I get the impression it was constantly restarting -- it always seemed to be in the activating state, but with a different pid each time I checked. 'systemd list-jobs' also showed this service with a different job id each time I ran the command. I was finally able to get out of this state by running 'systemctl mask --runtime apport-autoreport.service'.

This clearly doesn't look like an issue with the 5.8 kernel since I also see it with 5.4, so I'm removing the block-proposed tag.

tags: removed: block-proposed
Seth Forshee (sforshee) wrote :

I should note, I did not update systemd in isolation. I can provide a complete list of packages installed/upgrade at the same time if that is helpful.

Seth Forshee (sforshee) wrote :

These messages show up repeatedly in the journal:

Aug 19 21:33:11 ubuntu-x1 systemd[1]: Failed to start Process error reports when automatic reporting is enabled.
Aug 19 21:33:11 ubuntu-x1 systemd[1]: apport-autoreport.service: Start request repeated too quickly.
Aug 19 21:33:11 ubuntu-x1 systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'.

They stop when I mask the service.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
no longer affects: apport (Ubuntu)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in systemd (Ubuntu):
status: New → Confirmed

I am experiencing this same problem and I can confirm that when I mask the
apport-autoreport.service the problem stops.

I am on Ubuntu 20.10 with Kernel 5.8.0-18-generic. I also have Ubuntu 20.04
with Kernel 5.8.0-05-generic and
can confirm the problem does not happen there

John

Erwane (erwane) wrote :

Same here BUT ... I have delete the /var/crash/* and init splash stop to consume 100% cpu.

This is the clue :

```
sept. 18 15:15:26 rige systemd[1]: apport-autoreport.service: Succeeded.
sept. 18 15:15:26 rige systemd[1]: Finished Process error reports when automatic reporting is enabled.
sept. 18 15:15:26 rige systemd[1]: Starting Process error reports when automatic reporting is enabled...
sept. 18 15:15:27 rige whoopsie-upload-all[6386]: /var/crash/_usr_bin_software-properties-gtk.1000.crash already marked for upload, skipping
sept. 18 15:15:27 rige whoopsie-upload-all[6386]: /var/crash/_usr_bin_ibus-daemon.1000.crash already marked for upload, skipping
sept. 18 15:15:27 rige whoopsie-upload-all[6386]: /var/crash/_usr_bin_gnome-shell.125.crash already marked for upload, skipping
sept. 18 15:15:27 rige whoopsie-upload-all[6386]: /var/crash/_usr_libexec_tracker-extract.1000.crash already marked for upload, skipping
sept. 18 15:15:27 rige whoopsie-upload-all[6386]: /var/crash/_usr_share_discord_Discord.1000.crash already marked for upload, skipping
sept. 18 15:15:27 rige whoopsie-upload-all[6386]: /var/crash/_usr_lib_virtualbox_VBoxSVC.1000.crash already marked for upload, skipping
sept. 18 15:15:27 rige whoopsie-upload-all[6386]: /var/crash/_usr_lib_slack_slack.1000.crash already marked for upload, skipping
sept. 18 15:15:27 rige whoopsie-upload-all[6386]: All reports processed
sept. 18 15:15:27 rige systemd[1]: apport-autoreport.service: Succeeded.
sept. 18 15:15:27 rige systemd[1]: Finished Process error reports when automatic reporting is enabled.
```

Balint Reczey (rbalint) wrote :

Will be fixed in next upload, in 246.6-1ubuntu1
https://github.com/systemd/systemd/issues/16669

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.