I noticed a strange problem in my Kubuntu.

Immediately after logging in to KDE (either after reboot or just logging out), I can't use KDE's hotkeys and even can't start any KDE programs through menu. Alt+F2 isn't showing, too, and programs in autostart don't start. And nothing helps until I go to menu, start a non-KDE terminal (e.g. gnome-terminal) and run

Code: Select all

sudo systemsettings

After entering password, all previously launched (but not worked) commands are executed, and after it I can use my desktop as usually.

What can it mean? Maybe one of KDE's internal communication services isn't working? How to check which one?

before things started not working did you do an update, add something to autostart or add a new widget?

this is very strange, does running any KDE app as root also alleviate the issue or only systemsettings

what I'd do is:
- test as a new/diff user to see if it's a system wide issue and if not a system wide issue then:
-- open ksysguard to see if any app is using all the cpu or disk
-- disable all autostarted apps (can use systemsettings for KDE apps, but also look in ~/.config/autostart)
-- set plasma desktop to default

Code: Select all

kquitapp plasma-desktop
 sleep 20s
 mkdir -p $HOME/plasma-config/
 mv $(kde4-config --localprefix)/share/config/plasma-desktop* $HOME/plasma-config/
plasma-desktop &

greatperson wrote:What can it mean? Maybe one of KDE's internal communication services isn't working? How to check which one?

Firstly I'd question why you're opening GUI apps using

Code: Select all

sudo systemsettings

for example, and not

Code: Select all

kdesudo systemsettings

Start by checking the ownership of the scripts set to autostart and read up on the differences between sudo and kdesudo.

You may also wish to just wait - it could be a script timing out.

Sorry for long timeout, I've managed to unsubscribe this topic and forgot about it... Now, I answer your questions.

google01103 wrote:before things started not working did you do an update, add something to autostart or add a new widget?

I'm afraid that I reboot my computer too rarely to analyze what was updated since last reboot. So, I think the answer is «yes, I did an update», but I can't tell which update it was.

google01103 wrote:this is very strange, does running any KDE app as root also alleviate the issue or only systemsettings

Any sudo'ed KDE app does this: dolphin, konsole, kate, ... Even sudo klipper does, but I have two running Klippers after that.

google01103 wrote:- test as a new/diff user to see if it's a system wide issue and if not a system wide issue then:

Created and tried absolutely new user — and the user doesn't have the problem.

google01103 wrote:-- open ksysguard to see if any app is using all the cpu or disk

I can't open KSysGuard because it's a KDE app, and it doesn't run until I solve the problem. sudo ksysguard «solves» the problem the same way as sudo systemsettings does.

google01103 wrote:-- disable all autostarted apps (can use systemsettings for KDE apps, but also look in ~/.config/autostart)

All I had in autostart was Akregator, KTorrent, Amarok and my own small PHP script (which was autostarted for years without problems). OK, I deleted it all through System Settings. In ~/.config/autostart I found two Xfce's .desktop files and deleted them, too. This didn't help.

pagoda wrote:read up on the differences between sudo and kdesudo.

I start apps with sudo because kdesudo doesn't work. All kdesudo's dialogs I try to call appear later, after a simple sudo starts a KDE program. Kdesudo seems to be a usual KDE app in this context.

google01103 wrote:-- set plasma desktop to default

Code: Select all

kquitapp plasma-desktop
 sleep 20s
 mkdir -p $HOME/plasma-config/
 mv $(kde4-config --localprefix)/share/config/plasma-desktop* $HOME/plasma-config/
plasma-desktop &

It helped! But is there a way to find out where was the problem exactly? In one of plasmoids?..

only way to determine which plasmoid is bad is to add them back one at a time, plasmoids that access non-local disks or the internet can be the problem if they can't reach the desired resource

fyi - using sudo instead of kdesudo to run gui apps can cause permission (ownership) issues

fyi (2) - if you can't run ksysguard you can run in either atop or htop in a terminal, there's also a qt app called qps

Hmm... OK, I'm a stupid idiot. Maybe the problem really was caused with my PHP script. (But it works for years! for years, really! what changed??)

The script checks some data from internet and alerts (using kdialog) if something changed. It needs network to work correctly, so when it can't connect to server, it calls system('sleep 30') in hope that network will appear in 30 seconds. Could it stop remaining system loading?.. Has something in KDE's autostart system changed? I always thought that the script is running in a separate process and can't cuse the whole system to sleep...

Well, currently the problem seems to be solved, even with my old Plasma settings.

what if you change your script so that the sleep command is run first

I have seen this before, and can confirm what you have seen.
Scripts autostarted by KDE *must* ensure they fork off as soon as possible otherwise they will hold up the entire startup process.
Easiest way to do this is by having the shell script which runs your php command do this:

Code: Select all

php /path/to/file.php &

bcooksley wrote:Easiest way to do this is by having the shell script which runs your php command do this:

Code: Select all

php /path/to/file.php &

Thanks, this really helps.