Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Plasma6 session in tigervnc: kglobalaccel 100% CPU
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
Havin_it
Veteran
Veteran


Joined: 17 Jul 2005
Posts: 1271
Location: Edinburgh, UK

PostPosted: Fri Jun 28, 2024 2:10 pm    Post subject: Plasma6 session in tigervnc: kglobalaccel 100% CPU Reply with quote

Hi,

Context: I'm running a plasma-6 X11 session on my laptop under tigervnc Xvnc. I normally start this by logging in on a console VT and running "vncserver :1" but the behaviour is the same if I use the initscript. Non-systemd profile.

When first connecting from another machine (typically using tigervnc client on Windows), everything is initially OK, but:

1. As soon as any key is pressed, kglobalacceld starts eating 100% CPU. At this point there are no other issues.

2. If kglobalacceld is killed, the session is stable but obviously minus the shortcuts kglobalaccel provides (shortcuts within apps, such as tab-switching in Yakuake, still work, but the global shortcut to open/close Yakuake does not).

3. If kglobalacceld is then re-launched, CPU stays calm, but now keyboard input is completely deactivated: no keystroke has any effect at all. In addition there are some weird UI quirks that suggest it "sees" multiple modifier-keys as being stuck down: for example, scroll-wheel on any window or the panel changes its opacity. It basically renders the session unnavigable.

There are no such issues in a proper, SDDM-launched plasma-x11 session, or in a Fluxbox session in the Xvnc context.

This is not an entirely novel issue: kglobalaccel5 had exactly the same CPU-thrash behaviour under Xvnc, but the difference was that after killing and relaunching it, it behaved perfectly. In plasma6, there seems no way to get it to recover.

I'd welcome advice on how to dig into this issue. Since I've just upgraded from KDE5 I feel a fresh profile might be an idea, but now that ~/.kde is not all in one neat bundle that seems harder to do. I'm also not sure whether this is likely to be classifiable as a KDE bug, a KDE-not-using-systemd bug or even a tigervnc bug (pretty sure a bugreport has to be made as a next step from here).
Back to top
View user's profile Send private message
js08
n00b
n00b


Joined: 04 Mar 2008
Posts: 47

PostPosted: Wed Nov 06, 2024 12:56 am    Post subject: Reply with quote

I have this issue too but not only when logged in under tigervnc on my server (supermicro amd-epyc platform).
KDE6 is definitely no improvement - I had this nice little feature already for at least 2 or 3 years also under KDE5.
My dirty workaround is to kill this process periodically via cron every hour.
_________________
Train Hard Or Don't Train At All
Back to top
View user's profile Send private message
Havin_it
Veteran
Veteran


Joined: 17 Jul 2005
Posts: 1271
Location: Edinburgh, UK

PostPosted: Wed Nov 06, 2024 2:16 am    Post subject: Reply with quote

Hi js08,

Sorry to hear that but can you elaborate on "[...] not only when logged in under tigervnc"? Do you mean "not just once after I login (recurs repeatedly)" or "not just in tigervnc (also in proper Xorg session)"?

Also this for me is kglobalacceld eating 100% (or one core) continuously; If that's what is happening on your server, why only kill it hourly?
Back to top
View user's profile Send private message
belze
n00b
n00b


Joined: 21 Jul 2007
Posts: 17

PostPosted: Fri Dec 06, 2024 9:12 am    Post subject: Reply with quote

I have this problem too. I thought plasma 6.2.x had a fix for this issue somewhere, but I can't find a reference atm, just a volatile record in my silly memory. I'll switch back to lxqt waiting for a robust alternative for my use case: remote unattended initiation of a session like i'm using tightVNC for years. Too bad plasma's wayland session needs to be starded locally in order to enable wayland sharing or whatever is called, I can't test since the other end is too far away. If i'm wrong please give me an advice.

edit: just a hint, i'm using systemd
edit2: cross posted on upstream: https://bugs.kde.org/show_bug.cgi?id=306352 and https://bugs.kde.org/show_bug.cgi?id=489840
That's not the right place, but I hope gentoo packages for qt and kde read this thread: THANK YOU FOR YOUR WORK.
Back to top
View user's profile Send private message
Havin_it
Veteran
Veteran


Joined: 17 Jul 2005
Posts: 1271
Location: Edinburgh, UK

PostPosted: Sat Dec 07, 2024 4:20 pm    Post subject: Reply with quote

Hi belze,

Sorry to hear you're having these issues too. Just to be 100% clear: can you confirm that kglobalacceld is the process that starts hammering CPU?

The first of the bugs you joined #306352 was closed because a developer had done some work for 6.2 that they expected to solve it for at least *some* of the contributors for that *very old* bug. It didn't for me, and nobody else has responded yet - see my comment there (last before yours) as to why I didn't reopen it myself.

The other one #489840, I reported because the previous one was so old and covered too much ground between different people. It made some progress but the current diagnosis from it is that it's TigerVNC's bug. And there I get stuck because TigerVNC only support systemd.

This is why I want to see if you are definitely getting the same bug as me: because if you are, under systemd, then a TigerVNC bug report can be raised.
Back to top
View user's profile Send private message
belze
n00b
n00b


Joined: 21 Jul 2007
Posts: 17

PostPosted: Wed Dec 11, 2024 8:52 am    Post subject: Reply with quote

Havin_it wrote:
Hi belze,

Sorry to hear you're having these issues too. Just to be 100% clear: can you confirm that kglobalacceld is the process that starts hammering CPU?

The first of the bugs you joined #306352 was closed because a developer had done some work for 6.2 that they expected to solve it for at least *some* of the contributors for that *very old* bug. It didn't for me, and nobody else has responded yet - see my comment there (last before yours) as to why I didn't reopen it myself.

The other one #489840, I reported because the previous one was so old and covered too much ground between different people. It made some progress but the current diagnosis from it is that it's TigerVNC's bug. And there I get stuck because TigerVNC only support systemd.

This is why I want to see if you are definitely getting the same bug as me: because if you are, under systemd, then a TigerVNC bug report can be raised.


Sorry for being late.
I can confirm:

  • I'm on systemd
  • kglobalacceld is eating 100% CPU as soon as TigherVNC unit is started even if i'm not logged in
  • if i configure VNC to start lxqt instead, I don't have this problem.

[/list]
Back to top
View user's profile Send private message
Havin_it
Veteran
Veteran


Joined: 17 Jul 2005
Posts: 1271
Location: Edinburgh, UK

PostPosted: Wed Dec 11, 2024 11:37 am    Post subject: Reply with quote

Don't worry, I have been on this case years now, I have developed a little patience :wink:

You already commented on my KDE bug but I may do a followup just to ask advice from the dev who helped me debug it there for reporting the issue to TigerVNC.

There is some other good news from plasma-6.2: kglobalacceld can once again be made to behave itself if you kill and restart it (that hadn't been true since plasma-5). As you are doing all this remotely, you'll need a way to make this happen automatically when the Plasma session starts, so here's what I've added to do that:

1. This is a script to kill and restart kglobalacceld whenever it runs at over 90% CPU for a few seconds. I wrote it as a "daemon" (running continuously) because for me sometimes the bug can recur (like if I use xdotool). I saved it as /usr/local/bin/kgabonkd.
Code:
#!/bin/sh

EXE=/usr/libexec/kglobalacceld

# High CPU level to check for
LIMIT=90

# Check this often (in seconds) for CPU spiking
STEP=8

# Check this often for CPU spike continuing
QSTEP=2

# Set this to false if you do not want a desktop notification when bonk occurs
POPUP=true
if ! which kdialog &>/dev/null; then
        POPUP=false
fi

HICNT=0

while true; do
        EPID=$(pidof $EXE)
        if [ -z "$EPID" ]; then
                sleep $STEP
                continue
        fi
        CPU=$(top -b -n 2 -d 0.2 -p $EPID | tail -1 | awk '{print $9}'|awk -F '.' '{print $1}')

        SLEEPFOR=$STEP
        if [ $CPU -gt $LIMIT ]; then
                if [ $((HICNT++)) -eq 0 ]; then
                        SLEEPFOR=$QSTEP
                else
                        pkill -f $EXE
                        $POPUP && kdialog --passivepopup "Bonked $EXE at ${CPU}%" 5
                        sleep 1
                        $EXE &
                        HICNT=0
                fi
        fi
        sleep $SLEEPFOR
done

To run it requires sys-process/procps, sys-apps/coreutils and sys-apps/gawk (which you probably already have) and kde-apps/kdialog if you want desktop notifications when it acts.

To make it run when your Plasma session starts, create a file ~/.config/autostart/kgabonkd.desktop with this inside:
Code:
[Desktop Entry]
Exec=/usr/local/bin/kgabonkd
Icon=application-x-shellscript
Name=kgabonkd
Type=Application
X-KDE-AutostartScript=true


Hope that's some help. It's been enough to let me return to using Plasma as my everyday VNC desktop, but obviously I'm still keen to see the bug squashed. With your input I may be a step closer to that goal.
Back to top
View user's profile Send private message
belze
n00b
n00b


Joined: 21 Jul 2007
Posts: 17

PostPosted: Fri Dec 13, 2024 9:49 am    Post subject: Reply with quote

Havin_it wrote:
Don't worry, I have been on this case years now, I have developed a little patience :wink:

You already commented on my KDE bug but I may do a followup just to ask advice from the dev who helped me debug it there for reporting the issue to TigerVNC.

There is some other good news from plasma-6.2: kglobalacceld can once again be made to behave itself if you kill and restart it (that hadn't been true since plasma-5). As you are doing all this remotely, you'll need a way to make this happen automatically when the Plasma session starts, so here's what I've added to do that:

1. This is a script to kill and restart kglobalacceld whenever it runs at over 90% CPU for a few seconds. I wrote it as a "daemon" (running continuously) because for me sometimes the bug can recur (like if I use xdotool). I saved it as /usr/local/bin/kgabonkd.
Code:
#!/bin/sh

EXE=/usr/libexec/kglobalacceld

# High CPU level to check for
LIMIT=90

# Check this often (in seconds) for CPU spiking
STEP=8

# Check this often for CPU spike continuing
QSTEP=2

# Set this to false if you do not want a desktop notification when bonk occurs
POPUP=true
if ! which kdialog &>/dev/null; then
        POPUP=false
fi

HICNT=0

while true; do
        EPID=$(pidof $EXE)
        if [ -z "$EPID" ]; then
                sleep $STEP
                continue
        fi
        CPU=$(top -b -n 2 -d 0.2 -p $EPID | tail -1 | awk '{print $9}'|awk -F '.' '{print $1}')

        SLEEPFOR=$STEP
        if [ $CPU -gt $LIMIT ]; then
                if [ $((HICNT++)) -eq 0 ]; then
                        SLEEPFOR=$QSTEP
                else
                        pkill -f $EXE
                        $POPUP && kdialog --passivepopup "Bonked $EXE at ${CPU}%" 5
                        sleep 1
                        $EXE &
                        HICNT=0
                fi
        fi
        sleep $SLEEPFOR
done

To run it requires sys-process/procps, sys-apps/coreutils and sys-apps/gawk (which you probably already have) and kde-apps/kdialog if you want desktop notifications when it acts.

To make it run when your Plasma session starts, create a file ~/.config/autostart/kgabonkd.desktop with this inside:
Code:
[Desktop Entry]
Exec=/usr/local/bin/kgabonkd
Icon=application-x-shellscript
Name=kgabonkd
Type=Application
X-KDE-AutostartScript=true


Hope that's some help. It's been enough to let me return to using Plasma as my everyday VNC desktop, but obviously I'm still keen to see the bug squashed. With your input I may be a step closer to that goal.


WOW this is very helpful, I'll test as soon as possible.

edit: tested. I'm on zsh so I tried some variant of:
Code:

└─[$]> LANG=C /bin/bash /usr/local/bin/kgabonkd
/usr/local/bin/kgabonkd: line 31: [: 0,0: integer expression expected
/usr/local/bin/kgabonkd: line 31: [: 0,0: integer expression expected
/usr/local/bin/kgabonkd: line 31: [: 0,0: integer expression expected
^C


I'm not a bash script guru but I can see that this line is:

Code:

        if [ $CPU -gt $LIMIT ]; then

Anyway, you're not supposed to fix this, beacuse there is nothing to fix.
---

Have you already submit this issue to TigerVNC?
Back to top
View user's profile Send private message
Havin_it
Veteran
Veteran


Joined: 17 Jul 2005
Posts: 1271
Location: Edinburgh, UK

PostPosted: Fri Dec 13, 2024 2:32 pm    Post subject: Reply with quote

Oh bother, my scripting ineptitude is showing :oops:

I'm not certain but I have a feeling that the top command that gets the process's CPU usage is giving slightly different output on your system, so the commands I piped it through to isolate the number are ending up with "0,0" instead of the percentage. If you could show me output of the following command I can probably do you a fix.
Code:
top -b -n 2 -d 0.2 -p $(pidof /usr/libexec/kglobalacceld)

There's probably a tool somewhere that outputs the CPU of a process more neatly, but I don't know of it.

I haven't started bugging TigerVNC yet. I commented again on the KDE bug, hoping to get a little more feedback from the dev who helped me there in order to help me work out what exactly I'm gonna say to TigerVNC (I followed debugging steps given but this stuff is at the edge of my understanding tbh). If no reply there in the next week or so, I'll go ahead and file a TigerVNC bug with a pointer to the KDE bug and the best summary I can muster. I'll post a link here when I've done so.

EDIT TO ADD: While commenting on the KDE bug I thought of something else that might be helpful to build the picture. You said you're using LxQt as a fallback VNC desktop; could you please install x11-misc/xdotool and try executing it in your LxQt/VNC session, to see if it has any effect? Obviously it won't show in kglobalacceld as it won't be running, but in KDE it makes the Xvnc server do something that overwhelms kglobalacceld ("flood of SocketNotifier events") - I wonder if it will have any effect on another Qt-based desktop. A simple commandline to test would be

Code:
xdotool type something
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22830

PostPosted: Fri Dec 13, 2024 3:35 pm    Post subject: Reply with quote

Perhaps this percentage field tries to be locale-aware, and prints 0,0 in locales where comma separates the whole and fractional parts of a number, but prints 0.0 in locales where comma is a thousands-separator and period separates the whole and fractional parts of a number. I see that OP has a location of UK, but I have dealt with enough users who set their program locale different from their country of residence that I am not going to assume OP uses a GB locale.
Back to top
View user's profile Send private message
Havin_it
Veteran
Veteran


Joined: 17 Jul 2005
Posts: 1271
Location: Edinburgh, UK

PostPosted: Fri Dec 13, 2024 4:23 pm    Post subject: Reply with quote

Hu wrote:
Perhaps this percentage field tries to be locale-aware, and prints 0,0 in locales where comma separates the whole and fractional parts of a number, but prints 0.0 in locales where comma is a thousands-separator and period separates the whole and fractional parts of a number. I see that OP has a location of UK, but I have dealt with enough users who set their program locale different from their country of residence that I am not going to assume OP uses a GB locale.


I'm en_GB.UTF8 over 'ere. I didn't ask but wondered why @belze was prefixing with LANG=C but that doesn't alter the output for me. I barely understand how i18n/l10n works at the best of times :oops:

Explanation makes sense of the output though, whatever the explanation. So this should work as a replacement for that line:
Code:
CPU=$(top -b -n 2 -d 0.2 -p $EPID | tail -1 | awk '{print $9}' | sed s/'\W.*$'//)
Back to top
View user's profile Send private message
belze
n00b
n00b


Joined: 21 Jul 2007
Posts: 17

PostPosted: Tue Dec 17, 2024 9:33 am    Post subject: Reply with quote

Havin_it wrote:
Oh bother, my scripting ineptitude is showing :oops:

I'm not certain but I have a feeling that the top command that gets the process's CPU usage is giving slightly different output on your system, so the commands I piped it through to isolate the number are ending up with "0,0" instead of the percentage. If you could show me output of the following command I can probably do you a fix.
Code:
top -b -n 2 -d 0.2 -p $(pidof /usr/libexec/kglobalacceld)

There's probably a tool somewhere that outputs the CPU of a process more neatly, but I don't know of it.

I haven't started bugging TigerVNC yet. I commented again on the KDE bug, hoping to get a little more feedback from the dev who helped me there in order to help me work out what exactly I'm gonna say to TigerVNC (I followed debugging steps given but this stuff is at the edge of my understanding tbh). If no reply there in the next week or so, I'll go ahead and file a TigerVNC bug with a pointer to the KDE bug and the best summary I can muster. I'll post a link here when I've done so.

EDIT TO ADD: While commenting on the KDE bug I thought of something else that might be helpful to build the picture. You said you're using LxQt as a fallback VNC desktop; could you please install x11-misc/xdotool and try executing it in your LxQt/VNC session, to see if it has any effect? Obviously it won't show in kglobalacceld as it won't be running, but in KDE it makes the Xvnc server do something that overwhelms kglobalacceld ("flood of SocketNotifier events") - I wonder if it will have any effect on another Qt-based desktop. A simple commandline to test would be

Code:
xdotool type something

I'm always late, still:
Code:

└─[$]> top -b -n 2 -d 0.2 -p $(pidof /usr/libexec/kglobalacceld)
top - 09:29:51 up 1 day, 9 min,  7 users,  load average: 8,78, 5,20, 4,17
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
%Cpu(s): 13,6 us,  7,4 sy,  0,0 ni, 39,5 id, 39,5 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :  21930,6 total,    288,1 free,   6909,6 used,  15197,9 buff/cache     
MiB Swap:  24575,0 total,  20501,4 free,   4073,6 used.  15021,0 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
1283352 myuser   20   0 1092068  81240  67844 S   0,0   0,4   0:00.24 kglobalacceld

top - 09:29:51 up 1 day, 9 min,  7 users,  load average: 8,78, 5,20, 4,17
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
%Cpu(s): 10,5 us,  4,6 sy,  0,4 ni, 40,9 id, 43,0 wa,  0,0 hi,  0,4 si,  0,0 st
MiB Mem :  21930,6 total,    288,1 free,   6909,6 used,  15197,9 buff/cache     
MiB Swap:  24575,0 total,  20501,4 free,   4073,6 used.  15021,0 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
1283352 myuser   20   0 1092068  81240  67844 S   0,0   0,4   0:00.24 kglobalacceld


I modified your script as suggested and I think it's now working nicely! A HUGE THANK YOU for this early Christmas gift!

I'll try to install x11-misc/xdotool and test lxqt to help adding some info.
Back to top
View user's profile Send private message
belze
n00b
n00b


Joined: 21 Jul 2007
Posts: 17

PostPosted: Tue Dec 17, 2024 9:38 am    Post subject: Reply with quote

Havin_it wrote:

EDIT TO ADD: While commenting on the KDE bug I thought of something else that might be helpful to build the picture. You said you're using LxQt as a fallback VNC desktop; could you please install x11-misc/xdotool and try executing it in your LxQt/VNC session, to see if it has any effect? Obviously it won't show in kglobalacceld as it won't be running, but in KDE it makes the Xvnc server do something that overwhelms kglobalacceld ("flood of SocketNotifier events") - I wonder if it will have any effect on another Qt-based desktop. A simple commandline to test would be

Code:
xdotool type something


Done. Nothing to report.
Code:
└─[$]> xdotool type something
something%

...and looking for 3-4 min ah htop not a single CPU spike (I stopped my dockers so load average got down to approx 0.5. Do you have any place (logs) where to look for errors or messages?

EDIT: I got back to plasma-X11 and tried xdotool and immediatly sow a nice kdialog about a bonked process. Your script is indeed very nice and I can thus reproduce your issue.
Back to top
View user's profile Send private message
Havin_it
Veteran
Veteran


Joined: 17 Jul 2005
Posts: 1271
Location: Edinburgh, UK

PostPosted: Tue Dec 17, 2024 2:24 pm    Post subject: Reply with quote

Happy it helped you too :)

Thanks for testing on LxQt. I wasn't really expecting anything to happen, and no I don't have any clue what an effect under other desktops would look like really, just maybe that some other process would spike perhaps. It's just another data-point to reinforce that while it only happens to KDE under TigerVNC, other desktops have no such issue under VNC so it looks like KDE is the cause as much as the victim, if you see what I mean.

No responses yet on the KDE bug so when I get time (probably the weekend) I'll file with TigerVNC and link it here when I've done so. I dunno whether much will come of that or if it'll just be blamed back on KDE, but if they have a look at least some more insight might come out. I'm only able to raise it with them because you've reproduced under systemd, so I got a nice pre-Christmas present too :)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum