https://bugs.kde.org/show_bug.cgi?id=422111
Sam Edwards <cfswo...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WAITINGFORINFO |---
Status|NEEDSINFO |CONFIRMED
Ever confirmed|0 |1
--- Comment #64 from Sam Edwards <cfswo...@gmail.com> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
