After closing everything, I now see lipstick talking to the lipstick scanner and at about one 5th the period, connman. dbus-monitor. and journald really sucks. in comparison to rsyslogd.
journald gets loaded if something is spamming it.
You can try editing /etc/systemd/journald.conf and either playing with the rate limiter, or settting something like MaxLevelStore=warning so it drops less interesting messages. But then you also can’t see them in the logs…
1 Like
In parallel I was sitting on a web proxy (haproxy), which does a fair bit of logging, watching rsyslog (so, web traffic, constant) not register. That machine, of course has a lot more cores 
I’m wondering, though, wouldn’t journald be set to be very conservative as a default? I’ll have to ask @piggz. It might be that he ships with somewhat more noisy logging.
I cannot edit the original post any more, and I can only add three tags 
So I’ll add here that more or less the same happens on 4.4.0.64 / Xperia 10iii as well as my original 4.2 / Xperia 10DS.
All of the information above this post was collected on the 10ds with 4.2.
1 Like
Thanks @nephros for the original report and all the additional info and discussion. I’ve created a report on our internal bug tracker, so have tagged this as “tracked”.
6 Likes
Good to know.
I have two ways to improve the exec() detail, one of which is a very K&R hodgepodge of chown+chmod, the other is this - but I suppose having udev depend on perl is not really feasible…
Although in synthetic performance (well, syscall count) benchmarks, perl is surprisingly lightweight, and does the job.
@Jolla: Has this issue been checked by Jolla, is there a solution ahead, which could be expected with a soon update?
2 Likes
@nephros - thank you for the bug report! In the last weeks/months I noticed a similar behaviour on my XA2 (4.5.0.24) which got worse until I found an Android app (Ö1) which was desperately trying to login - it was enabled to be started on boot (Settings => Apps => Allow background service to start on bootup)
Once I disabled this, my battery life went back to normal.
Systemd-logind is now at 2.1% CPU time when the display is on. I never did any traces …
2 Likes
I had a weird incident today where the phone went into power saving mode (the small leaf in the top status bar) while the battery was still way above 50%. It might come from excessive heat from sunshine, idk.
Anyhow, I now noticed the same behavior as reported by OP and some other users in this thread:
- systemd-logind eats a significant amount of CPU, but erratic, never 4x100%, according to htop
- nothing else pops out in htop - all the top CPU consumers are system apps like lipstick, pulseaudio, dbus-daemon. No stray processes afaics.
- identical output from
dbus-monitor --systemas shown by @karry - happens when display sleeps, stops when wake up
I did not strace anything.
The phone is not warm to the touch (been out of the sun for hours) but battery drain is significantly higher.
I will now connect the charger.
Coming out of power saving mode, but no change in described behavior.
Adding dmesg -w to my poor man’s debugging, the pattern repeats: It’s relatively quiet when the display is on, but each time it goes to sleep, this entry repeats many times per second:
[147725.492766] Freezing of tasks aborted after 0.006 seconds
[147725.492877] Restarting tasks ... done.
[147725.525654] PM: suspend exit 2024-05-17 20:32:23.810137181 UTC
[147725.578481] PM: suspend entry 2024-05-17 20:32:23.862969735 UTC
[147725.578493] PM: Syncing filesystems ... done.
[147725.631515] Freezing user space processes ...
[147725.638125] PM: Wakeup pending, aborting suspend
[147725.638329] active wakeup source: IPA_WS
Now I’ll reboot the phone.
And now messageserver5 is causing trouble again. Random fluke or related? Stopping/starting the service fixes that.
The systemd-logind issue is now gone according to htop, dmesg and dbus-monitor.
Things to note:
- All command line tests were done as root
- No apps were open (in the app grid) while testing
- Android App support has not been on the whole day
- I currently use the hotspot functionality every evening, it seems to work somewhat less than perfectly, but nothing like described in this post
… hence I think the “K&R hodgepodge of chown+chmod” is the more appropriate approach. May I suggest to actually pose a PR, so you might get Jolla’s opinion on this.
Edit: Second thought: Why not utilising /bin/sh in the same way you use Perl? No extra dependency, same result: Halving the number of exec calls (via RUN+= statements). Or am I missing some aspect?
I gave it a try here: [helpers/makeudev] Simplify by using Shell instead of Perl by Olf0 · Pull Request #1 · nephros/droid-hal-device · GitHub
Yes, AFAIK.
See udev manpage and e.g. “udev - ArchWiki” or “permissions - Making devices accessible to all users in a group - Ask Ubuntu”
⇒ A solution without any exec calls outside of udev should be possible.
100% same on XA2, 4.6.0.13. Programmers of Jolla, please fix this 3rd-year bug of Sailfish!
3 Likes
Same on Xperia 10 plus too
1 Like
Not on the Sony Xperia XZ2 Compact just 0,5%.
And also, may be someone knows here, how to reveal process, that don’t let cpu sleeping, and heats up it at 100% at background and then kill it! ? Crest, SystemDataScope, Lighthouse, “top” in Terminal don’t show it.
Such a process does not exist.
These tools show all processes.
Maybe a peripheral such as camera or gps could produce the heat and the throttling, without CPU usage per se.
Both are really low power. WLAN and the cellular “modem” (“baseband processor”, though that ceased to exist as a separate entity long ago) are medium power, i.e. if they are running wild, they could get the mobile phone at most lukewarm.
Futhermore @windes wrote:
that don’t let cpu sleeping, and heats up it at 100%
Though I wonder why he believes the CPU being at 100% load, when “Crest, SystemDataScope, Lighthouse, “top” in Terminal don’t show” anything special.
Because i see and believe in SystemDataScope cpu’s graph, that show straight line at 0% sleeping. And also i see how fast my battery drains in such “heat up” mode. And also i feel with hand, that phone becomes warm in this mode.
Sure, this apps show processes that actually using cpu. They can’t show what process don’t let phone to sleep!
Not sleeping might be a different problem, accounting towards battery drain nonetheless. Which phone was that? Any particular software installed recently? (e.g. Situations could trigger hardware usage)
(L.E. Not sleeping might be related to hardware peripherals usage, the ‘process’ being some code in the kernel driver. Not sure if perf tool for the kernel is in repos for official devices though)
1 Like