Plasmashell periodically freezing

[Duncan]

Bug Reporter posted on Thu, 31 May 2018 16:59:13 -0400 as excerpted:

> In the last two days Plasmashell has started freezing every hour or so.
> 
> QMake version 3.1
> Using Qt version 5.11.0 in /usr/lib
> plasmashell 5.12.5
> Linux laptop 4.16.12-1-ARCH #1 SMP PREEMPT Fri May 25 23:30:31 UTC 2018
> x86_64 GNU/Linux

Whatever you're running (arch?), I'm impressed.  That's rather newer
versions of things than most distros provide. =:^)  Of course the down side
of that is that while such new versions often fix some bugs, they also tend
to bring both a few of their own, and some in depending packages simply due
to them not yet being adjusted to match, which may be what you're seeing
here.

FWIW, running live-git kde-plasma/frameworks/apps here, with plasmashell
--version reporting 5.13.80 (aka 5.14-alpha?) and konsole's about reporting
frameworks 5.47 (again, actually live-git), on qt 5.11.0-rc2 (tho konsole's
about reports it as 5.11.0), because live-git plasma and/or frameworks now
requires qt 5.10+, and gentoo doesn't seem to have a 5.10 at all, but had
an earlier 5.11-beta masked (because various packages had yet to be updated
to be able to build with it), so after unmasking I could switch to it and
continue running kde live-git (only a couple minor packages I was actually
running had problems with 5.11-pre, and I was able to find or create
patches for them).

While I've not seen such freezes with (live-git) plasmashell recently,
I do have some experience with the issue at times in the (kde4 era) past,
and, while I'm not sure the same issue applies to plasma5, and if it does
there's some caveats, it's still worth considering for troubleshooting
purposes.

Back in the kde4 era at least, plasma(shell) single-threaded all its
plasmoids (aka widgets), so if one stalled for whatever reason, it froze
the entire shell!(!!!)  Given that the entire plasma ecosystem encouraged
people to create and share their own plasmoids with the world, letting
any of them freeze the entire plasma desktop was... let's just say not
the best implementation choice.

OK, so the plasma5 era caveat I mentioned is that even if the above still
applies to "native" code, in the plasma5 era, qt-scripted plasmoids are
strongly encouraged and much more common, and AFAIK, they should /not/
freeze the entire desktop.

> I can recover with these commands:
> killall plasmashell
> plasmashell > /dev/null 2>&1 & disown

<nod>  Yes, given past experience I'm rather familiar with that dance.
In fact, I've used it so much that I have it along with a number of similar
"reset" scriptlets (kwin-x11 --replace, being one example) invokable via
hotkey.  I've not had to use those hotkeys so much recently, but it's still
nice to know they're available should I find I need them.

> How should I debug this? I don't see anything relevant in the systemd
> journal.

The first thing I'd try is opening a terminal window (konsole or whatever)
and issuing the killall/restart commands from there -- but leaving it open.
Plasmashell should thus spit out all its debugging stuff to its STDERR,
the konsole window, and you can see if anything stands out from about the
time the desktop freezes.  Unfortunately, that tends to produce so much
very dire looking but generally harmless "noise" that unless you're
familiar with the standard spew and can mentally filter it out, even if
the problem does show up there it's difficult to separate it from the
noise.  But it's worth a try.

The second thing I'd try is running a default plasma desktop for awhile,
to see if the problem shows up there.  If it does, then you've eliminated
your customizations from the equation and know it's something in "the
system".  If it doesn't, then you know it's something to do with your
customizations and can troubleshoot from there which one.

There's a couple levels of this.  Most of the plasmoid and container
configuration is stored in a single file...

plasma-org.kde.plasma.desktop-appletsrc

Due to customized XDG* paths here mine is in a non-default location, but
I *THINK* the default should be something like

~/.config/plasma-org.kde.plasma.desktop-appletsrc

Whatever your path to this file, BACK IT UP first to somewhere safe, then
with plasmashell shut down, delete the working copy.  You can then restart
plasmashell and it should come up with a generic default setup.

Run with that for awhile and see if it freezes after the hour or so.

If it doesn't, you know the problem is the configuration of something in
that file, and you can (with plasmashell shut down again) restore it from
backups and restart plasma, then start deleting customizations you've made
until you find the problem.  Or go the other way and recustomize the
generic one, step by step, until the problem comes back (tho it may not,
the problem might have been in some cruft in the old file that didn't get
updated correctly in an upgrade for some reason, that won't reappear when
reconfigured from default).

If the problem is still there with a default desktop-appletsrc config, then
try nuking more of the config back to generic, the easiest way being
creating a new "test" user with a clean home dir and thus an entirely
generic config.  Or after backing up elsewhere, simply delete everything
in your home dir so you're running generic.

If that cures the problem, then you know it's somewhere in your config,
and you can try bisecting, tho common sense can help you shorten the
process from a blind bisect.  The idea of a bisect is to recursively
split the problem in half, testing to see if it's good or bad.  If it's
good, you know the problem is in the other half.  If it's bad, it's in
the half you tested.  Either way, take half of the bad half (thus a
quarter, then an eighth, etc) and test again.

Eventually you'll get down to single bad dir, then a single bad file
within it.  At that point, depending on what that file is and the
settings it controls, you can choose to either simply delete and
recreate from default, or, assuming it's a text-based config file
(as most kde config is), try diving into the file itself, until
you get to an individual setting line.

Of course if it's a file like the above desktop-appletsrc, it controls
a whole lot still, but while nominally being an ini-style config file,
it's not really designed to be edited by hand, and while it can be
done (I've done it), it requires rather more patience, time, and technical
mindset than many people have.

> The only thing I have done recently that might be related to this is that
> by mistake I ran the following command:
> 
> chmod -R 770 /home/
> 
> To attempt to fix that, I went through and reset permissions like this:
> 
> find /home -mount -type f -exec chmod 660 {} \;
> chmod 644 /home/*./.bash*
> chmod 600 /home/*./.bash_history
> chmod 700 /home/*/.ssh
> find /home/*/.ssh -mount -type f -exec chmod 600 {} \;
> 
> Could the Plasma freezing be related to file permissions in /home? If so,
> which permissions do I need to check / fix?

770 perms for kde config files shouldn't be an issue.  In fact, I routinely
set some files read-only (4xx perms), in ordered to prevent unwanted
overwrites with garbage, if something goes wrong, and it "just works".
Even 000 perms, no access, shouldn't be an issue, as it should then simply
fall back to builtin defaults.

I believe it far more likely that either you have a misbehaving plasmoid
stalling the whole thing (tho as I said I'm not entirely sure that's even
possible in plasma5 any more, but it definitely was in plasma4), or it's
a system problem, possibly due to some qt-5.11 incompatibility, and the
above revert-to-generic and try method should help you figure out which
of the two to look further into.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman