sudo systemctl stop systemd-journal*
Really? This seems odd.
Any numbers, benchmarks? Otherwise what do you mean by significant?
Could make sense I guess if something has gone berserk and is logging “non-stop”. However stopping journaling in that case wouldn’t be addressing the underlying problem.
It may be good to check whether you are controlling the total disk usage used by journaling. https://source.puri.sm/Librem5/community-wiki/-/wikis/Tips%20&%20Tricks#managing-journals
Also, are you mirroring journal entries to syslog? (same link as previous)
2 Likes
I actually ran into an issue being automatically logged out of my profile when stopping journalctl too soon and removed it from my startup script. After running for a while with it on again it doesn’t have quite the impact that I originally thought it did. I think these are helping more:
killall gnome-software (excessive background cpu)
using mosh for my ssh tunnels home
removing gnome-clocks (excessive background cpu)
zram for memory compression (fixed the need for memory pressure settings I used previously in sysctl.conf
e4defrag on /var/log /usr /home (in my update script)
journalctl --vacuum-size=200M (in my update script)
My benchmark right now is general snappyness while docked to my uperfect mini
The reason I’ve been so fixated on journalctl is due to it every couple seconds hitting 100% cpu. I read a couple things that say it only uses cpu when logs are being written but while tailing the logs this doesn’t seem to be true.
I DO still feel a slight improvement with it off but I’m not sure how to be more scientific in measuring it. I’d like to minimize cpu usage whereever possible due to temperature/charging.
That was a good trick to remind - I’d forgotten to set those. Freed a few gigs worth of precious eMMC.
Also, set some other limitations on journalctl’s activity from that conf - an alternative to killing it completely (wasn’t bothering me but it’s still good to set some boundaries).
gnome-clocks shouldn’t eat any CPU in background and doesn’t for me.
zram is configured by default.
If journald is eating a lot of CPU, it most likely means you have a problem somewhere else. It doesn’t even show up in powertop here. Could be related to that gnome-clocks thing.
Start with:
sudo journalctl --follow
and see whether something keeps spewing things into logs. journalctl --user --follow may be worth checking too.
1 Like
I’m not sure if its due to the image I installed but zram was def not installed for me. I’m happy if its normally installed by default since it has such a huge impact on usability.
Those are the commands I tried but as I said, the cpu keeps spiking on an interval regardless of activity
purism@pureos:~$ sudo journalctl --user --follow
No journal files were found.
^C
purism@pureos:~$ sudo journalctl --follow
-- Journal begins at Sat 2023-07-22 09:37:11 EDT. --
Jul 27 10:40:08 pureos phoc[628]: [types/output/cursor.c:354] Failed to render cursor buffer
Jul 27 10:40:08 pureos phoc[628]: [types/output/cursor.c:223] Failed to get cursor display formats
Jul 27 10:40:08 pureos phoc[628]: [types/output/cursor.c:269] Failed to pick cursor format
Jul 27 10:40:08 pureos phoc[628]: [types/output/cursor.c:354] Failed to render cursor buffer
Jul 27 10:40:08 pureos phoc[628]: [types/output/cursor.c:223] Failed to get cursor display formats
Jul 27 10:40:08 pureos phoc[628]: [types/output/cursor.c:269] Failed to pick cursor format
Jul 27 10:40:08 pureos phoc[628]: [types/output/cursor.c:354] Failed to render cursor buffer
Jul 27 10:42:06 pureos sudo[314107]: pam_unix(sudo:session): session closed for user root
Jul 27 10:42:08 pureos sudo[314992]: purism : TTY=pts/0 ; PWD=/home/purism ; USER=root ; COMMAND=/usr/bin/journalctl --follow
Jul 27 10:42:08 pureos sudo[314992]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
^CWhoops can’t run journalctl --user --follow with sudo. I’m seeing more activity
Tons of that cursor message
Jul 27 10:47:49 pureos phoc[628]: [types/output/cursor.c:223] Failed to get cursor display formats
Jul 27 10:47:49 pureos phoc[628]: [types/output/cursor.c:269] Failed to pick cursor format
Jul 27 10:47:49 pureos phoc[628]: [types/output/cursor.c:354] Failed to render cursor buffer
Jul 27 10:47:49 pureos phoc[628]: [types/output/cursor.c:223] Failed to get cursor display formats
Jul 27 10:47:49 pureos phoc[628]: [types/output/cursor.c:269] Failed to pick cursor format
Jul 27 10:47:49 pureos phoc[628]: [types/output/cursor.c:354] Failed to render cursor buffer
Jul 27 10:47:49 pureos phoc[628]: [types/output/cursor.c:223] Failed to get cursor display formats
Jul 27 10:47:49 pureos phoc[628]: [types/output/cursor.c:269] Failed to pick cursor format
Jul 27 10:47:49 pureos phoc[628]: [types/output/cursor.c:354] Failed to render cursor buffer
Jul 27 10:47:49 pureos phoc[628]: [types/output/cursor.c:223] Failed to get cursor display formats
Jul 27 10:47:49 pureos phoc[628]: [types/output/cursor.c:269] Failed to pick cursor format
Jul 27 10:47:49 pureos phoc[628]: [types/output/cursor.c:354] Failed to render cursor bufferSo that’s the actual problem you’re having:
I’ve seen this on my nexdock. Would explain why sometimes the phone locks up, especially when I have brave open on the external display?