1

systemd is using 100% continually ... here is top

top - 19:47:09 up 13 min,  1 user,  load average: 3.26, 2.62, 1.69
Tasks: 306 total,   4 running, 294 sleeping,   0 stopped,   8 zombie
%Cpu(s): 35.5 us, 12.6 sy,  0.0 ni, 51.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  11858.2 total,   5183.4 free,   3433.2 used,   3241.6 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.   7913.7 avail Mem
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                    
  1 root      20   0  268660 110536   8532 R 100.0   0.9  11:39.36 systemd                                                                                    
772 message+  20   0   10988   6768   4116 R  46.0   0.1   5:16.01 dbus-daemon                                                                                
259 root      19  -1  496536 327492 325464 S  16.8   2.7   2:16.95 systemd-journal                                                                            
796 syslog    20   0  221104   5832   4052 S  13.9   0.0   1:38.00 rsyslogd                                                                                   
804 root      20   0  103380  93880   7784 S  13.1   0.8   1:34.41 systemd-logind                                                                             
 18 root      20   0       0      0      0 S   0.7   0.0   0:00.55 ksoftirqd/1                                                                                

1733 root 20 0 352968 130376 83760 S 0.7 1.1 0:25.47 Xorg
1916 ava 20 0 4008000 272576 117864 S 0.7 2.2 0:32.40 gnome-shell
3877 ava 20 0 2629148 269672 162688 S 0.7 2.2 0:09.53 Web Content

here is the system log

 sudo tail -n 100 /var/log/syslog
Aug 13 19:46:11 kiev systemd[1]: Failed to start Process error reports when automatic reporting is enabled.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Start request repeated too quickly.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'.
Aug 13 19:46:11 kiev systemd[1]: Failed to start Process error reports when automatic reporting is enabled.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Start request repeated too quickly.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'.
Aug 13 19:46:11 kiev systemd[1]: Failed to start Process error reports when automatic reporting is enabled.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Start request repeated too quickly.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'.
Aug 13 19:46:11 kiev systemd[1]: Failed to start Process error reports when automatic reporting is enabled.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Start request repeated too quickly.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'.
Aug 13 19:46:11 kiev systemd[1]: Failed to start Process error reports when automatic reporting is enabled.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Start request repeated too quickly.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'.
Aug 13 19:46:11 kiev systemd[1]: Failed to start Process error reports when automatic reporting is enabled.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Start request repeated too quickly.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'.
Aug 13 19:46:11 kiev systemd[1]: Failed to start Process error reports when automatic reporting is enabled.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Start request repeated too quickly.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'.
Aug 13 19:46:11 kiev systemd[1]: Failed to start Process error reports when automatic reporting is enabled.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Start request repeated too quickly.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'.
Aug 13 19:46:11 kiev systemd[1]: Failed to start Process error reports when automatic reporting is enabled.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Start request repeated too quickly.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'.

here is some of dmesg

[    3.942656] systemd[1]: Inserted module 'autofs4'
[    4.005635] systemd[1]: systemd 246-2ubuntu1 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[    4.025381] systemd[1]: Detected architecture x86-64.
[    4.046020] systemd[1]: Set hostname to <kiev>.
[    4.132974] systemd[1]: /lib/systemd/system/docker.socket:6: ListenStream= references a path below legacy directory /var/run/, updating /var/run/docker.sock → /run/docker.sock; please update the unit file accordingly.
[    4.137916] systemd[1]: /lib/systemd/system/dbus.service:12: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.
[    4.164397] systemd[1]: /lib/systemd/system/plymouth-start.service:17: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.
[    4.193000] systemd[1]: /lib/systemd/system/gdm.service:30: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether.

this happened after my last system update ... same after reboot and/or another system update ... any ideas ?

ubuntu 20.04

2 Answers2

3

As a temporary workaround: Delete all files under /var/crash/ It is not a long or even medium term solution, but better then nothing for a start.

2

old obsolete solution see below UPDATE for better approach

just shut off the out of control service apport

sudo systemctl disable apport-autoreport 
#  sudo apt-get purge apport    #  avoid it works yet is too heavy handed
sudo apt-get purge apport-noui

then after a reboot systemd cpu usage was normal yet

tracker-miner-fs

was using 100% cpu even after another reboot so I issued

gsettings set org.freedesktop.Tracker.Miner.Files crawling-interval -2  
gsettings set org.freedesktop.Tracker.Miner.Files enable-monitors false
echo y | LANG=en tracker reset --hard

now all is well

UPDATE

edit file /usr/lib/systemd/system/apport-autoreport.path

#  PathExistsGlob=/var/crash/*.crash  #  <-- old bad comment it out

PathChangedGlob=/var/crash/*.crash # good new replaces above line

save then issue

sudo systemctl daemon-reload

for details see https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1891657

Here we are months later after this issue has been resolved below is contents from a healthy normal box ( Ubuntu 20.04 as of 20210812 )

cat /usr/lib/systemd/system/apport-autoreport.path

[Unit] Description=Process error reports when automatic reporting is enabled (file watch) ConditionPathExists=/var/lib/apport/autoreport

[Path] PathExistsGlob=/var/crash/*.crash

[Install] WantedBy=paths.target

  • You might try removing the package 'apport-noui' instead of removing apport altogether as apport is part of most desktop tasks. – Brian Murray Sep 02 '20 at 21:53
  • After your updated solution, do you reboot, or does the systemctl command stop the journald process? – Jason Mehmel Aug 12 '21 at 19:51
  • @JasonMehmel I cannot recall however my guess is box was OK after issuing the daemon reload command otherwise I would have mentioned it needed a reboot – Scott Stensland Aug 13 '21 at 01:22
  • 1
    @ScottStensland fair enough! I tried your solution and got an error at the daemon reload command, but this was also after an upgrade to 21.04 so it's possible there were other things in play! I ended up just hard rebooting my machine and the journald cpu usage stopped. – Jason Mehmel Aug 13 '21 at 21:11