Bug 422111

Still an issue after 5.19 shipped on arch.

Can I have someone's ~/.config/plasma-org.kde.plasma.desktop-appletsrc please

Created attachment 129238 [details]
~/.config/plasma-org.kde.plasma.desktop-appletsrc

Requested config file attached.

https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/62

Patch above fixes it for me, battery applet is back, thanks.
I assume it's going to land in 5.19.1?

*** Bug 422678 has been marked as a duplicate of this bug. ***

Huh, somehow my landed commit message is broken which is why this didn't autoclose

*** Bug 421779 has been marked as a duplicate of this bug. ***

Hi, I updated to 5.19.1 and this bug is still happening. When starting my laptop or waking it up from sleep randomly makes applet to dissappear. When I add the applet manually it says no batteries available.
Below is the info that I copied from info center.

Operating System: Manjaro Linux
KDE Plasma Version: 5.19.1
KDE Frameworks Version: 5.71.0
Qt Version: 5.15.0
Kernel Version: 5.7.4-1-MANJARO
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz
Memory: 11.6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520

Created attachment 129538 [details]
Screenshot with info center and battery applet

That looks like a slightly different issue. Can you file a new bug report please? Thanks!

Unfortunately, this bug is still here. 
Since the update to 5.19.1 this is the second time it appears, now i have documented it. An attachment has been added. 

Operating system: KDE neon 5.19
KDE Plasma version: 5.19.1
KDE Frameworks version: 5.71.0
Qt version: 5.14.2
Kernel: 5.3.0-59-generic
OS type: 64-bit
Processors: 4 × Intel® Core™ i5-3320M CPU @ 2.60GHz
Memory: 7,6 GiB di RAM
Graphic processor: Mesa DRI Intel® Ivybridge Mobile

Created attachment 129580 [details]
Screenshot with battery icon missing.

Created attachment 129581 [details]
Plasma applets confi file.

*** Bug 423347 has been marked as a duplicate of this bug. ***

Re-opening as we're getting reports from people using 5.19.1 that it's still not fixed. :(

Happening for me on a fresh 5.19.2 config.

I can confirm it, not yet fixed, despite choosing "always shown" in the tray settings. Plasma wayland session.

------------------------------
Operating System: Arch Linux
KDE Plasma Version: 5.19.2
KDE Frameworks Version: 5.71.0
Qt Version: 5.15.0
Kernel Version: 5.6.19.a-1-hardened
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz
Memory: 7,6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520

Update: After logging out and logging in, the icon is shown... But still, it didn't show up when I selected "Always shown".

Can I see the output of:

qdbus org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames

from someone experiencing this with new Plasma

(In reply to David Edmundson from comment #20)
> Can I see the output of:
> 
> qdbus org.freedesktop.DBus /org/freedesktop/DBus
> org.freedesktop.DBus.ListNames
> 
> from someone experiencing this with new Plasma

org.freedesktop.DBus
org.freedesktop.Notifications
org.freedesktop.Akonadi.Resource.akonadi_birthdays_resource
org.freedesktop.PowerManagement
:1.8
org.kde.kappmenu
:1.9
org.kde.kaccess
org.freedesktop.Akonadi.Agent.akonadi_imap_resource_0
org.freedesktop.Akonadi.Agent.akonadi_contacts_resource_0
org.kde.korgac
org.freedesktop.Akonadi.Agent.akonadi_maildispatcher_agent
org.kde.pim.TransportManager
org.kde.kdeconnect
org.freedesktop.Akonadi.Agent.akonadi_unifiedmailbox_agent
org.freedesktop.Akonadi.Agent.akonadi_maildir_resource_0
org.kde.dolphin-6080
org.kde.krunner
org.kio5.kio_http_cache_cleaner
:1.60
org.freedesktop.Akonadi.Resource.akonadi_unifiedmailbox_agent
org.freedesktop.Akonadi.Resource.akonadi_maildir_resource_0
:1.40
org.a11y.Bus
org.kde.StatusNotifierHost-643
:1.41
org.kde.GtkConfig
:1.42
org.freedesktop.Akonadi.Agent.akonadi_ical_resource_0
org.freedesktop.Akonadi
:1.20
org.kde.kmail
:1.43
org.kde.klauncher5
:1.21
:1.152
:1.44
:1.22
org.kde.konsole-16634
:1.45
:1.23
org.kde.kscreen.osdService
org.freedesktop.Akonadi.Agent.akonadi_mailfilter_agent
:1.46
org.kde.Solid.PowerManagement
org.freedesktop.PowerManagement.Inhibit
:1.47
:1.25
org.freedesktop.Akonadi.Agent.akonadi_archivemail_agent
:1.48
:1.26
org.kde.kmail2
org.kde.plasma.browser_integration
org.kde.screensaver
org.kde.KWin
org.freedesktop.Akonadi.Agent.akonadi_akonotes_resource_0
:1.29
ca.desrt.dconf
org.freedesktop.Akonadi.Agent.akonadi_newmailnotifier_agent
org.freedesktop.Akonadi.NewMailNotifierAgent
org.freedesktop.ScreenSaver
org.freedesktop.Akonadi.Resource.akonadi_imap_resource_0
org.freedesktop.Akonadi.Resource.akonadi_contacts_resource_0
org.kde.plasmashell
org.kde.plasmanetworkmanagement
org.freedesktop.Akonadi.Control
local.org_kde_powerdevil
org.freedesktop.Akonadi.Agent.akonadi_sendlater_agent
org.kde.kglobalaccel
org.freedesktop.FileManager1
org.freedesktop.Akonadi.Agent.akonadi_followupreminder_agent
org.kde.kdeconnect.daemon
org.kde.kwalletd5
org.freedesktop.Akonadi.Janitor
org.kde.polkit-kde-authentication-agent-1
org.freedesktop.Akonadi.MailDispatcherAgent
com.canonical.Unity
org.freedesktop.Akonadi.Agent.akonadi_migration_agent
org.freedesktop.Akonadi.Resource.akonadi_ical_resource_0
org.kde.kded5
org.mozilla.firefox.ZGVmYXVsdC1yZWxlYXNl
:1.50
org.kde.ActivityManager
:1.51
:1.30
:1.53
:1.31
org.freedesktop.Akonadi.Control.lock
:1.54
org.kde.kuiserver
:1.10
:1.55
:1.33
:1.11
:1.34
:1.12
org.kde.StatusNotifierWatcher
:1.165
:1.57
org.kde.JobViewServer
:1.35
org.freedesktop.Akonadi.Resource.akonadi_akonotes_resource_0
:1.13
:1.58
org.freedesktop.Akonadi.Agent.akonadi_indexing_agent
:1.36
:1.1
:1.14
:1.167
org.freedesktop.Akonadi.Agent.akonadi_birthdays_resource
:1.37
:1.15
:1.38
:1.3
org.kde.ksmserver
:1.147
:1.39
org.kde.kcookiejar5
:1.17
org.kde.Solid.PowerManagement.PolicyAgent
:1.18
:1.6
:1.19

I just restarted plasma, and successfully had it not appear (running 5.19.2)

$ qdbus org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames
org.freedesktop.DBus
org.freedesktop.Notifications
:1.227
org.freedesktop.PowerManagement
org.kde.kappmenu
org.kde.kaccess
org.freedesktop.systemd1
org.pulseaudio.Server
org.kde.KScreen
:1.250
org.kde.klauncher5
:1.251
:1.23
org.kde.kscreen.osdService
:1.253
:1.231
org.freedesktop.PowerManagement.Inhibit
org.kde.Solid.PowerManagement
:1.254
:1.233
:1.234
:1.235
org.kde.KWin
org.kde.screensaver
ca.desrt.dconf
:1.236
:1.237
:1.238
org.freedesktop.ScreenSaver
:1.239
org.kde.plasmashell
org.kde.plasmanetworkmanagement
org.kde.konsole-51945
local.org_kde_powerdevil
org.kde.kglobalaccel
org.kde.kwalletd5
org.PulseAudio1
org.kde.polkit-kde-authentication-agent-1
com.canonical.Unity
org.kde.kded5
org.kde.ActivityManager
org.kde.keyboard
org.kde.kuiserver
:1.240
org.kde.StatusNotifierHost-51566
org.kde.StatusNotifierWatcher
:1.241
org.kde.JobViewServer
:1.0
:1.242
:1.243
:1.244
org.kde.ksmserver
org.kde.kcookiejar5
:1.246
org.kde.Solid.PowerManagement.PolicyAgent
:1.247
:1.248

Then, after a kquitapp & kstart plasmashell, (which makes it appear pretty consistently):

$ qdbus org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames
org.freedesktop.DBus
org.freedesktop.Notifications
:1.227
org.freedesktop.PowerManagement
org.kde.kappmenu
org.kde.kaccess
org.freedesktop.systemd1
org.pulseaudio.Server
org.kde.KScreen
:1.250
org.kde.klauncher5
:1.251
:1.23
org.kde.kscreen.osdService
:1.253
:1.231
org.freedesktop.PowerManagement.Inhibit
org.kde.Solid.PowerManagement
:1.233
org.kde.StatusNotifierHost-51999
:1.234
:1.257
:1.235
org.kde.KWin
org.kde.screensaver
:1.258
ca.desrt.dconf
:1.236
:1.237
:1.238
org.freedesktop.ScreenSaver
:1.239
org.kde.plasmashell
org.kde.plasmanetworkmanagement
org.kde.konsole-51945
local.org_kde_powerdevil
org.kde.kglobalaccel
org.kde.kwalletd5
org.PulseAudio1
org.kde.polkit-kde-authentication-agent-1
com.canonical.Unity
org.kde.kded5
org.kde.ActivityManager
org.kde.keyboard
:1.260
org.kde.kuiserver
:1.240
org.kde.StatusNotifierWatcher
:1.241
org.kde.JobViewServer
:1.0
:1.242
:1.244
org.kde.ksmserver
org.kde.kcookiejar5
:1.246
org.kde.Solid.PowerManagement.PolicyAgent
:1.247
:1.248

New information was added with recent comments; chaning status for inspection.

Still have this bug on openSUSE Tumbleweed with plasma 5.19.3

Same issue on Manjaro with Plasma 5.19.3.

I don't see this issue.

Operating System: Arch Linux
KDE Plasma Version: 5.19.4
KDE Frameworks Version: 5.73.0
Qt Version: 5.15.0
Kernel Version: 5.7.12-arch1-1
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5 CPU M 430 @ 2.27GHz
Memory: 7.5 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics

Set Battery and Brightness (Automatic Load) in system tray config to Always shown, icon appears in system tray.

When set to Shown when relevant, icon disappears. Disconnect AC, icon appears. Reconnect AC (still full charge), icon disappears. Reconnect AC (part discharge), icon remains until charged.

Same problem here on OpenSuse Tumbleweed and Plasma 5.19.5
On first login battery is not shown. After I logout and login again bettery is shown.

Same problem here on openSUSE Tumbleweed. Login - Logout - Login required to make the battery symbol visible. 

Operating System: openSUSE Tumbleweed 20200925
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.1
Kernel Version: 5.8.10-1-default
OS Type: 64-bit
Processors: 8 × AMD Ryzen 7 4700U with Radeon Graphics
Memory: 7.1 GiB of RAM
Graphics Processor: AMD RENOIR

I'm also seeing this bug on Manjaro Linux. It pops back up after a restart.

Operating System: Manjaro Linux
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.1
Kernel Version: 5.8.11-1-MANJARO
OS Type: 64-bit
Processors: 4 × AMD Ryzen 3 3250U with Radeon Graphics
Memory: 5.8 GiB of RAM
Graphics Processor: AMD RAVEN2

This is fixed for me on OpenSuSe Tumbleweed with Plasma 5.20

Can anyone else confirm? Are other people who were seeing this in 5.19 able to confirm the fix in 5.20?

(In reply to Nate Graham from comment #32)
> Can anyone else confirm? Are other people who were seeing this in 5.19 able
> to confirm the fix in 5.20?

It's here, in Neon it happened to me the other day, just after 5.20 update.
It is absolutely random, you don't see it for weeks and when you think an update has magically fixed it, it reappears. For this matter, I suspect it is some kind of race condition on start.

Bleh. :(

Hello, I jump in to bump it up:
same problem here, randomly.

neofetch --off gives
OS: Arch Linux x86_64 
Host: VivoBook_ASUSLaptop X412DA_X412DA 1.0 
Kernel: 5.9.1-arch1-1 
Uptime: 19 mins 
Packages: 923 (pacman) 
Shell: zsh 5.8 
Resolution: 1920x1080 
DE: Plasma 5.20.1 
WM: KWin 
WM Theme: Breeze 
Theme: Breeze Dark [Plasma] 
Icons: breeze-dark [Plasma] 
Terminal: konsole 
CPU: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx (4) @ 2.600GHz 
GPU: AMD ATI 03:00.0 Picasso 
Memory: 1759MiB / 5949MiB

*** Bug 428896 has been marked as a duplicate of this bug. ***

Are you sure that Bug 428896 is duplicate? Because after system start I see icon just fine with correct percentage, but then it disappears when some state changes. 

Anyway I did see also problem described in this issue, but not with 5.20. So it seem this issue is fixed for me with 5.20.

Yes, it seems semi-random.

This issue just appeared on my Manjaro with 5.20.3. When I started notebook, there was no battery icon present. When I switched applet from disabled to always shown, it did appeared however with message that no battery was detected.

*** Bug 429703 has been marked as a duplicate of this bug. ***

*** Bug 430044 has been marked as a duplicate of this bug. ***

(In reply to Andrew Brouwers from comment #23)
> Then, after a kquitapp & kstart plasmashell, (which makes it appear pretty
> consistently):
> org.kde.Solid.PowerManagement


hmm, org.kde.Solid.PowerManagement *is* there both before and after, so doesn't seem an issue of the dbus server being absent.

Seems to affect very few people and reports are old.

#39 may be valid, but is describing something very unrelated. 

I've reviewed the modern code on this and it all looks fine now - though I do recall making some changes at some point to a hypothetical race with DBus activated items.

Closing unless someone can reproduce with 5.21 or provide some more useful information

I just ran into this on Fedora 34 KDE Spin, running Plasma 5.21.4. org.kde.Solid.PowerManagement is in the output of that qdbus command for me. Is there any other info I can provide? Because I do still get this every now and then, and I'm experiencing it now.

Another report from 5.21: Bug 436911

Re-opening.

*** Bug 436911 has been marked as a duplicate of this bug. ***

*** Bug 436911 has been marked as a duplicate of this bug. ***

Persists on plasma 5.22.1.

Not sure if its related, but this time, it happened after installing plasma/kf updates, and relogging without rebooting.

Is there anything I could look out for in my ~/.config/plasma-org.kde.plasma.desktop-appletsrc?

Operating System: Gentoo Linux
KDE Plasma Version: 5.22.1
KDE Frameworks Version: 5.83.0
Qt Version: 5.15.2
Kernel Version: 5.10.45-gentoo (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i5-7200U CPU @ 2.50GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 620

Happens to me too, but it's not consistently gone. Sometimes icon is present, sometimes it's not. I did not make any "deep" tests, but it feels like icon is missing after system went to sleep and woke up. After reboot icon [usually] is present again.

Sorry for double-posting, I'll add some info.
When I say "icon is missing", ofc I mean that normally it would be shown (for example, now I have like 70% of battery, and in tray settings it is set to be always shown - but it is not, and it's also missing from "expanded" tray ("show hidden icons")).

I've tried to set "Always show all entries" in systray's properties - I can see everything except for battery :)

I don't know if that's still actual, but:
> David Edmundson 2020-06-29 14:40:55 UTC
> Can I see the output of:
> qdbus org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames

Here it is: https://gist.github.com/alexandrpaliy/06012b961bdb463ec3f488260ddba469

*** Bug 350365 has been marked as a duplicate of this bug. ***

Probably relevant bug: https://gitlab.freedesktop.org/upower/upower/-/merge_requests/24 upstream

But in solid `Solid::Battery::ChargeState Battery::chargeState` we don't event use pending states, this marked "TODO".

I suspect some hardware use those states but not others.

I have a tentative patch to improve on the situation
https://invent.kde.org/frameworks/solid/-/merge_requests/43

If someone affected by the issue could test it, that would be great (I am not affected by the bug on my Dell laptop).

I'm on 5.22.2 with frameworks 5.83.0 and rebooted 12 times, observing this bug 4 out of the 12 times, so it happens with roughly 30% probability.

After applying the above patch, the battery applet was not present on the very next boot, so it isn't sufficient to prevent this bug. :(

Killing and restarting the `plasmashell` process always restores the battery applet, though.

I found something can help to fix problem
add sleep 30 in /etc/xdg/autostart/powerdevil.desktop
like down
Exec= sleep 30 && /usr/lib/org_kde_powerdevil

i test in my system and its fixed

Operating System: Arch Linux 
KDE Plasma Version: 5.22.3
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.2
Kernel Version: 5.12.15-arch1-1

Thanks for that information, but that's not a fix for everyone, that's a local workaround for you. :) Your workaround points to a race condition somewhere.

Asking a different question, does restarting powerdevil after an issue fix it?

It appears that a restart of powerdevil does cause the battery applet to appear.

Are there any logging settings I should consider turning on? It feels like powerdevil/plasmashell are deciding that my laptop is really a desktop (i.e. no battery) when first deciding whether to instantiate the battery applet, as a result of not yet discovering the battery.

That is really useful information, we've constantly been debugging races in plasmashell <--> powerdevil

not powerdevil <--> upower

Please can someone insert this in their env (really really early, like /etc/profile.d/)

QT_LOGGING_RULES=org.kde.powerdevil.debug=true

and try and get me some logs.

Created attachment 140102 [details]
org.kde.powerdevil debug log when battery applet does NOT appear

Created attachment 140103 [details]
org.kde.powerdevil debug log when battery applet DOES appear

As requested, here are the logs. Nothing stands out to me as an obvious culprit, but maybe the (power)devil's in the details.

I was able to reproduce this issue without rebooting (I was starting the session from the terminal and using "log off" each time). It seemed to happen with a 90% rate under these circumstances. My upowerd PID was not changing between sessions, so we can rule out a race against upowerd's startup.

(Yes, my laptop is on battery power; detecting no AC power is expected.)

I'll next try restarting only powerdevil a few dozen times, unless a better diagnostic is proposed here.

I have just spent the past half-hour restarting powerdevil and plasmashell, including giving each one a head-start ranging from a few ms to a few hundred ms. The battery applet appeared every single time without fail.

I can't make the issue occur in an *existing* session, only if I restart the entire desktop session does it (have a chance to) happen. Some third component must be involved at some level, so I tried adding kded5 to the mix for a few attempts to no avail.

I'll keep trying to find the relevant process(es) between which this race is happening.

Reading powerdevil code, we expect Battery::isPowerSupply to be valid at the time of adding the device. 

Otherwise we track it as a m_peripheralBatteriesPercent an never update which map it should be in.

My gut guess based on the above is that this isn't loaded on time? Are you able to build powerdevil and add some debug in onDeviceAdded? Or maybe in solid?

Failing that `sudo dbus-monitor --system` before logging in might contain some clues?

I'm on Gentoo so adding arbitrary patches isn't even an inconvenience. :)

Sadly, Battery::isPowerSupply() is true even when the bug occurs, so I don't think it's that. But I have a better hypothesis as to what the culprit may be...

---

Two observations (for USERS):

a) This seems to affect only systemd systems. Is anyone experiencing this issue NOT USING SYSTEMD?

b) Using the systemdBoot option is a pretty good workaround for this issue:
kwriteconfig5 --file startkderc --group General --key systemdBoot true
...but that's probably only because (the user's) systemd starts things in an order that obviates the race condition, so not really a "fix" but should provide some relief until then.

---

A few things I've learned while debugging (for DEVELOPERS):

1) This issue is not specific to any video output method -- I have observed it on Wayland, Xorg, and now my current tests are done on Xephyr. I'm also now using a freshly-created user account, so we can rule out the possibility that this is because of some configuration setting that I changed to something other than its default.

2) This bug never happens when I restart plasmashell and/or powerdevil in an existing session, even if that session had the bug initially.

3) This bug never happens when I create a session for my test user account via sudo and run startplasma-x11 from it.

4) This bug occasionally happens when I create a session using machinectl, but only if I have recently run a Plasma session for that user from a TTY.

5) This bug often (>90%) happens when I run startplasma-x11 for my test user account via TTY.

So, this really smells like a race in interacting with logind, since it lines up pretty well with what logind considers a "fresh session" (scenario #3 above isn't a new session, scenario #4 is a new session but without a seat, and scenario #5 is a new session with a seat where powerdevil might want to dig deeper into the current session information, resulting in the bug).

I can see there's a fair amount of code in powerdevilpolicyagent.cpp; David, if you could highlight a few lines in there that look suspect, I'll be happy to see what I can do about tracing them.

In the meantime, I want to understand better why a `machinectl shell` session only has the bug if a Plasma session was run for the user from a TTY. I suspect it has something to do with which context spawned the dbus-daemon, but that's only a hunch.

I've been using the systemd startup feature since it was introduced and have never seen it happen FWIW.

I think we're off to a false start by looking at powerdevil (although it may be useful to know WHY this happens)

I added a bunch of debug messages to applets/systemtray/dbusserviceobserver.cpp. When this issue happens, the "org.kde.Solid.PowerManagement" service is absent from the list(s) processed in DBusServiceObserver::serviceNameFetchFinished(), but present in the list output from qdbus; I also get a serviceUnregistered() for it when I kill powerdevil.

When restarting plasmashell, it comes back up during a time when the PowerManagement service is already registered, so it appears in the service list, and the battery applet appears.

When restarting powerdevil, plasmashell receives the service-registered event when PowerManagement is re-registered, and the battery applet appears.

The following are always present in the serviceNameFetchFinished lists, whether the issue happens or not: "org.kde.powerdevil.chargethresholdhelper", "local.org_kde_powerdevil", "org.kde.powerdevil.discretegpuhelper", "org.kde.powerdevil.backlighthelper"

So, powerdevil is alive at the time the systemtray initializes, but (probably because it's delayed by a few ms to talk to logind) hasn't registered the PowerManagement service yet; it instead gets registered during a time that, for some reason, the QDBusServiceWatcher doesn't report it.

The serviceRegistered callback is working normally prior to the call to initDBusActivatables, as well as after both lists are returned. On a launch where the issue doesn't happen, the PowerManagement service shows up right after the lists are processed. Is there perhaps some window where the QDBusPendingCallWatcher is temporarily paused (or some bug with DBus itself) where the systemtray is momentarily blind to new services, and the issue happens because powerdevil is delayed just enough to register PowerManagement during that blind period?

Thanks for all your help so far

I am unaware of any reason that would happen.

From a DBus POV we quite explicitly:
 - create a match rules for a service being added, no-op locally
 - start an async fetch of services
 - once that's done we locally connect the match rule created above (unblock the m_dbusSessionServiceNamesFetched flag)

In theory nothing is racey.

Two theories:
 - can you confirm we always call registerPlugin with the right arg before initDBusActivatables
  - can you put some debug at the top of serviceRegistered and see if we're getting in there at all, there is an early return there


Assuming that matches up with the theory of DBus going awry I'll try and write a smaller text based test case we can run against.

Regarding theory 1: I was seeing the "Found DBus-able Applet" log for batterymonitor/PowerManagement before the init call
Regarding theory 2: My debug log was at the top of serviceRegistered

However, my debug log wasn't in the constructor's connect lambdas, so it's possible that the service is being registered while m_dbusSessionServiceNamesFetched is still false (i.e. after the handling of ListNames but before the delivery of the return value)

I'll check for that -- I might also want to get DBus running over TCP so I can capture the raw traffic.

My hunch looks like it was correct; the new log message I added fires off when the bug occurs:

kde.systemtray: m_sessionServiceWatcher->serviceRegistered( "org.kde.Solid.PowerManagement" ) but m_dbusSessionServiceNamesFetched=false

At this point, I'm pretty confident that the order of events is:

1) DBusServiceObserver is created and initialized, with m_dbusSessionServiceNamesFetched=false as per defaults. Plugins are registered, and the watcher has watch patterns added.
2) DBusServiceObserver::initDBusActivatables() is called; the async ListNames() request is sent to the session DBus
3) Session DBus server prepares a list of all services presently registered
4) powerdevil finishes initialization and registers the PowerManagement service (this happens after step 3 above, so it's not in the list)
5) ???
6) m_sessionServiceWatcher's serviceRegistered signal fires to inform DBusServiceObserver of #4, above
7) The async ListNames() call returns the list from #3, above

When the issue does NOT happen, steps 6<->7 are reversed

The mystery is what's going on in #5, causing these callbacks to run in a different order. As I see it, there are two possible culprits:

a) DBus itself: It might be that, while DBus does have strict ordering guarantees between a given pair of endpoints, no ordering guarantees exist with respect to a third endpoint. Hence, the race is between the org.freedesktop.DBus service's reply to ListNames() and powerdevil's (connection's) broadcast announcement of a newly-registered service.
b) Qt: It's possible that, since one signal comes by way of a QDBusPendingCallWatcher, and the other by way of a QDBusServiceWatcher, there are races in how the signals themselves are handled.

I find both of these cases pretty hard to believe, though. 'A' shouldn't be possible since dbus-daemon is single-threaded: if it is preoccupied handling/returning a ListNames() call, it can't even see the service registration request yet. But 'B' shouldn't be possible either if Qt is dispatching these signals in FIFO order and in the same thread that's reading the incoming messages off of the connection. (Maybe it doesn't?)

I'm going to try to get my session DBus rebound to 127.0.0.1 and do a Wireshark capture on lo. It'd be very helpful to know the actual order that dbus-daemon is sending these things to plasmashell.

dbus-monitor --pcap does seem to capture the root calls we want and is open-able in wireshark

all UIs (regular dbus-monitor/bustle) seems to filter them out

but I can see our match rules name NameAcquired signals

As for Qt - there are threads involved. 

Everything is in it's own thread, and then dispatched to the main thread. This /should/ still maintain order.

There is a code path that if someone else (plasma-nm!) makes a blocking call, we queue up all pending messages, and do process things out of order, but the code for handling everything we do queue still looks fine?

The env QDBUS_DEBUG=1 might help us?

I tried QDBUS_DEBUG=1; the extra output to the terminal slowed things down enough that the race stopped happening. I had to redirect stderr to a tmpfs-backed file to get the issue to happen again, but apparently redirecting stderr shuts off the other debug logs?

I had no luck with getting DBus running over TCP either. The session launched, but *slowly* -- it felt like the session launch kept blocking on something that had to time out before it could continue. Once again, no race condition. I didn't find it worthwhile to dig deeper.

The dbus-monitor --pcap worked, though. The messages are all in the expected order - the org.kde.Solid.PowerManagement registration signal arrives after the ListNames reply, despite the respective callbacks firing out of order. The timestamps indicate that the signal is ~32.4 ms after the ListNames request finishes, which is... quite the window, if those timestamps are accurate.

I'm not really sure how useful the dbus-monitor results are when DBus itself is a suspect, but I'm thinking we should be pointing the finger at Qt regardless. The single-threaded nature of dbus-daemon means they'd have to be *trying* to introduce message races, and with all of these threads in plasmashell, all it would take for a race there is for the two signals to take paths involving different threads. Perhaps most importantly, most of the earliest reports here are with Qt 5.15.0, which suggests this is a regression that appeared shortly after upgrading to the 5.15 series.

I don't understand what you mean about plasma-nm making a blocking call affecting plasmashell - isn't plasma-nm a different process? Wouldn't plasmashell be unaware of other calls into DBus and especially of whether those calls are performed in a blocking/nonblocking manner? Or are you talking about interactions between plasma-nm and plasmashell *via* DBus?

Happy to debug the queue replay code if you point me to the file that contains it! :)

*** Bug 442670 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/61

FWIW, that commit mentioned above won't change anything.

No worries, I figured as much. :)

Small update: I switched to a new laptop recently, and even when booting the exact same disk image, the problem doesn't happen for me at all anymore. I still have the old laptop for trying out patches, but I can't troubleshoot this problem quite as easily now.

This new laptop has 16 (logical) processors while the previous had 4. I'm wondering if this race only happens when all N threads used by KDE startup are forced to use a smaller set of processors (everybody else who has reported this has 8 or 4 processors). It might be worthwhile to try taking 12 of my processors offline and restarting KDE to see if that brings the race back.

Same here, Arch with Plasma 5.23.3 and Framework 5.88
With new laptop but LTS kernel (5.10.79)

*** Bug 444528 has been marked as a duplicate of this bug. ***

(In reply to ttv200 from comment #78)
> *** Bug 444528 has been marked as a duplicate of this bug. ***

Just to clarify, my report has similar symptoms, but battery icon is shown and it started happening at 5.23 i guess. It might be related, but not the same case.

Toshiba Z20t-C; Garuda Linux (it seems like lot of comments are from Arch-based distributions)

Any logs wanted?

*** Bug 445911 has been marked as a duplicate of this bug. ***

applet says no batteries available even though my python script is able detect battery percentage and give me warning as it is low
Plasma 5.23
output of journalctl /usr/bin/plasmashell -n 100 | grep battery                                                                                            ✔  39s  
Dec 08 09:48:01 manjaro-minion plasmashell[1263]: file:///usr/share/plasma/plasmoids/org.kde.plasma.battery/contents/ui/PowerProfileItem.qml:136: TypeError: Cannot read property 'label' of undefined

I would like to one new observation.
Recently I had removed my batteries for a couple of days.
Even then, Battery applet is missing somethings.

Lately, I have been experiencing this issue very often on my setup: openSUSE Tumbleweed, Plasma 5.23.5, KDE Frameworks 5.90.0, QT 5.15.2, Wayland.
While in the past years it happened very rarely (the battery icon in the tray would sometimes disappear after leaving the charger plugged in for some time, after reaching 100%), now it happens very often, and not only when charging. I log into my session, and the battery icon is already missing. Adding the "Battery and Brightness" object to the panel works as a workaround (I get the separate, bigger battery icon with the percentage in the panel, but outside the system tray).
Let me know if you need any additional piece of information/log/file/etc.

Hi everyone,
I recently uninstalled tlp and reinstalled powerdevil on my Arch+Plasma KDE. Every power issue (including disappearing bluetooth) has gone.
Hope that helps.

neofetch --off gives
------------------ 
OS: Arch Linux x86_64 
Host: VivoBook_ASUSLaptop X412DA_X412DA 1.0 
Kernel: 5.16.9-arch1-1 
Uptime: 2 mins 
Packages: 1161 (pacman) 
Shell: zsh 5.8.1 
Resolution: 1920x1080 
DE: Plasma 5.24.1 
WM: KWin 
Theme: Breeze Dark [Plasma], Adwaita [GTK3] 
Icons: [Plasma], Adwaita [GTK3] 
Terminal: konsole 
Terminal Font: mononoki 12 
CPU: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx (4) @ 2.600GHz 
GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series 
Memory: 1367MiB / 5943MiB

For the other people experiencing this, are you also using tlp?

Nate Graham píše v Pá 18. 02. 2022 v 19:18 +0000:
> https://bugs.kde.org/show_bug.cgi?id=422111
> 
> --- Comment #85 from Nate Graham <nate@kde.org> ---
> For the other people experiencing this, are you also using tlp?
> 

Not in my case, at least i really don't know about installing it and it
does not seem preinstalled on my distro.

I'm using Gnome now and did reinstall since laptop without battery life
was really hard to use, so i cannot be 100% sure.

I too see this issue

from /etc/os-release
> NAME="openSUSE Tumbleweed"
> VERSION_ID="20220217"

> plasmashell 5.24.1

`upower -d`  correctly shows the battery state and charge level.

`tlp` seems to be installed but I have never run it manually before, not sure if it runs automatically.

    $ systemctl status tlp
    ○ tlp.service - TLP system startup/shutdown
         Loaded: loaded (/usr/lib/systemd/system/tlp.service; disabled; vendor preset: disabled)
         Active: inactive (dead)


The CPU is Intel celeron, if it makes any difference being slower and all.

(In reply to Nate Graham from comment #85)
> For the other people experiencing this, are you also using tlp?

Nope. Actually, I have used it for a long time without ever experiencing this issue, and recently I uninstalled it and started using tuned instead. It was around this time that I first started experiencing this issue (I know this is probably a coincidence, but I am reporting it for the sake of completeness).

For workaround, go to System Tray Settings/Entries panel.
Set 'Battery and Brightness' to 'Disabled' (Apply).
Then set it back to 'Shown when relevant' (Apply).

Does this give a clue as to where the bug lies?

(In reply to flux from comment #89)
> For workaround, go to System Tray Settings/Entries panel.
> Set 'Battery and Brightness' to 'Disabled' (Apply).
> Then set it back to 'Shown when relevant' (Apply).

This does not seem to work for me, but restarting plasmashell works.

If we are suspecting startup order of something, then this is my journalctl log. I also have autologin enabled.

$ journalctl -b | grep autostart

Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/org.kde.plasmashell.desktop" ("/usr/bin/plasmashell")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/polkit-kde-authentication-agent-1.desktop" ("/usr/lib64/libexec/polkit-kde-authentication-agent-1")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/xprop-kde-full-session.desktop" ("/usr/bin/xprop", "-root", "-format", "KDE_FULL_SESSION", "32a", "-set", "KDE_FULL_SESSION", "1")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/xembedsniproxy.desktop" ("/usr/bin/xembedsniproxy")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/baloo_file.desktop" ("/usr/lib64/libexec/baloo_file")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/powerdevil.desktop" ("/usr/lib64/libexec/org_kde_powerdevil")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/kaccess.desktop" ("/usr/bin/kaccess")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/pulseaudio.desktop" ("/usr/bin/start-pulseaudio-x11")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/gmenudbusmenuproxy.desktop" ("/usr/bin/gmenudbusmenuproxy")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/xdg-user-dirs.desktop" ("/usr/bin/xdg-user-dirs-update")
Feb 20 21:59:16 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/geoclue-demo-agent.desktop" ("/usr/libexec/geoclue-2.0/demos/agent")

(In reply to flux from comment #89)
> For workaround, go to System Tray Settings/Entries panel.
> Set 'Battery and Brightness' to 'Disabled' (Apply).
> Then set it back to 'Shown when relevant' (Apply).

This does not seem to work for me, but restarting plasmashell works.

If we are suspecting startup order of something, then this is my journalctl log. I also have autologin enabled.

$ journalctl -b | grep autostart

Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/org.kde.plasmashell.desktop" ("/usr/bin/plasmashell")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/polkit-kde-authentication-agent-1.desktop" ("/usr/lib64/libexec/polkit-kde-authentication-agent-1")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/xprop-kde-full-session.desktop" ("/usr/bin/xprop", "-root", "-format", "KDE_FULL_SESSION", "32a", "-set", "KDE_FULL_SESSION", "1")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/xembedsniproxy.desktop" ("/usr/bin/xembedsniproxy")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/baloo_file.desktop" ("/usr/lib64/libexec/baloo_file")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/powerdevil.desktop" ("/usr/lib64/libexec/org_kde_powerdevil")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/kaccess.desktop" ("/usr/bin/kaccess")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/pulseaudio.desktop" ("/usr/bin/start-pulseaudio-x11")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/gmenudbusmenuproxy.desktop" ("/usr/bin/gmenudbusmenuproxy")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/xdg-user-dirs.desktop" ("/usr/bin/xdg-user-dirs-update")
Feb 20 21:59:16 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/geoclue-demo-agent.desktop" ("/usr/libexec/geoclue-2.0/demos/agent")

Hi everyone,
I also want to provide some more (maybe useful) information.
I am using plasma-desktop  5.24.2-1 on arch linux and also experience this bug (randomly either showing the battery monitor, or not).
Hardware is a Thinkpad T460s.

But in addition to the battery icon missing, also my hotkeys for adjusting the display brightness do not work.
I killed & restarted org_kde_powerdevil, and that made my hotkeys work again, but still no battery icon (just a display icon). Hovering that icon, it said something like "No batteries".

Restarting plasmashell, as mentioned above, fixed everything.

Hi.

I'm having the same issue and I'm wondering if powerdevil is required for the battery indicator to work. I already have upower and tlp installed and I can get battery readings and set thresholds to it. I can also see battery information on lock screen and kinfocenter.

Battery icon setting is 'always show'. I've tried with the separate widget but it doesn't show charge percentage and settings don't open, which I assume it's caused by missing powerdevil package.

All in all, I'm not installing powerdevil just because I'm already covered with tlp and I'm not sure if it will cause any conflicts.

Yes it is, and no it won't conflict.

(In reply to Nate Graham from comment #94)
> Yes it is, and no it won't conflict.

Thanks! Now it shows. I'm on Arch and I've installed powerdevil-light to avoid bringing a networkmanager-qt which I don't use.

I was expecting the icon to show up when charge is below the threshold, 40% in my case. Setting is 'visible when important' and laptop is connected to AC, maybe that's why.

Git commit ff834fc96548a0d61def108dea6f229437c6c8d7 by Nate Graham, on behalf of Jolene K.
Committed on 20/04/2022 at 15:32.
Pushed by ngraham into branch 'master'.

systemtray: Fix race in DBusServiceObserver

When a service appears right after the ListNames() call finished, but
before the QDBusPendingCallWatcher is set up, the ::serviceRegistered
signal will be queued before the ListNames() response. As a result,
the service will be ignored by DBusServiceObserver.

Switching to QDBusInterface::callWithCallback() ensures that the
result slot is queued as soon as the response arrives, thus avoiding
the race.

Credits go to Sam Edwards for identifying the problem in
https://bugs.kde.org/show_bug.cgi?id=422111#c69
FIXED-IN: 5.24.5

M  +38   -26   applets/systemtray/dbusserviceobserver.cpp
M  +7    -2    applets/systemtray/dbusserviceobserver.h

https://invent.kde.org/plasma/plasma-workspace/commit/ff834fc96548a0d61def108dea6f229437c6c8d7

Git commit 757b5e8c27a43a42d6a28c8dda66be08bf231b6a by Nate Graham, on behalf of Jolene K.
Committed on 20/04/2022 at 15:40.
Pushed by ngraham into branch 'Plasma/5.24'.

systemtray: Fix race in DBusServiceObserver

When a service appears right after the ListNames() call finished, but
before the QDBusPendingCallWatcher is set up, the ::serviceRegistered
signal will be queued before the ListNames() response. As a result,
the service will be ignored by DBusServiceObserver.

Switching to QDBusInterface::callWithCallback() ensures that the
result slot is queued as soon as the response arrives, thus avoiding
the race.

Credits go to Sam Edwards for identifying the problem in
https://bugs.kde.org/show_bug.cgi?id=422111#c69


(cherry picked from commit 3751f49cc5be219e63c7fae1df9f1b6e77f5762a)

M  +38   -26   applets/systemtray/dbusserviceobserver.cpp
M  +7    -2    applets/systemtray/dbusserviceobserver.h

https://invent.kde.org/plasma/plasma-workspace/commit/757b5e8c27a43a42d6a28c8dda66be08bf231b6a

(In reply to Christoph Sarnowski from comment #92)
> Hi everyone,
> I also want to provide some more (maybe useful) information.
> I am using plasma-desktop  5.24.2-1 on arch linux and also experience this
> bug (randomly either showing the battery monitor, or not).
> Hardware is a Thinkpad T460s.
> 
> But in addition to the battery icon missing, also my hotkeys for adjusting
> the display brightness do not work.
> I killed & restarted org_kde_powerdevil, and that made my hotkeys work
> again, but still no battery icon (just a display icon). Hovering that icon,
> it said something like "No batteries".
> 
> Restarting plasmashell, as mentioned above, fixed everything.

It seems to be still happening to me as well. OpenSuSE Leap 15.4 (Plasma 15.24.4)

Running the following after booting into KDE fixes it: killall plasmashell && kstart5 plasmashell

This is still happening for me too on Ubuntu 22.04 with KDE Plasma Version 5.27.4.

This is still happening. as of today march 2024 after upgrading manjaro to latest plasma version available.

Operating System: Manjaro Linux 
KDE Plasma Version: 5.27.11
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.12

inxi -B gives
Battery:
  ID-1: BAT0 charge: 58.4 Wh (64.7%) condition: 90.2/90.7 Wh (99.4%)

but org.kde.plasma.battery tells me "no batteries available" from the systray.

this is the first time I am affected by this bug.

also reported here: https://forum.endeavouros.com/t/missing-battery-status/38259
and here: https://bbs.archlinux.org/viewtopic.php?id=248579

This is a fairly old bug report and the code has changed a lot since it was reported. There's a very good chance the issue you're experiencing is caused by something else, even if the outward symptoms look and feel the same. Can you please submit a new bug report? Thank you!