Registered Member
|
Hello there, I'm new to this forum and I hope to do everything right.
When I startup KDE, the desktop config is messed up. I had four desktops configured individually and now it's ignoring all the config and showing me four standard desktops (all desktop-icons and backgrounds, .. gone). Obviously, my /home/user/.kde4/share/config/plasma-desktop-appletsrc is modiefied at startup time by plasma-desktop. I did a diff -y to show all changes against the original file:
plasma-desktop seems to alter the desktop config and setting "desktop=-1" for all four existing desktops and then adding four new, "empty" desktops. I can reproduce this by executing kquitapp "plasma-desktop; plasma-desktop". I even tried it with the altered config file and started up KDE again. Then plasma-desktop set all four new desktops (containments 90-94) to desktop=-1 and added another four desktops! If I delete the whole file "plasma-desktop-appletsrc", it is created from the scratch and seems to work fine, even after a restart. But that's not what i need. I now tested for a few days and really rarely it happened that KDE started without altering the file and showing me the correct desktops. I somehow guess that this is some kind of race condition within the launching sequence of plasma-desktop. I'm using a live system and a unionfs-layer for the /home directory which is mounted via /usr/share/config/kdm/Xstartup script (BEFORE KDE starts the session so all user-specific plasma config files should already be accessible when plasma-desktop starts). I first ran into this issue after updating KDE. As there were Kernel and QT updates as well, i can't tell the source of all troubles. Maybe these version info helps: 3.8.13-gentoo KDE 4.10.4 qtcore 4.8.4-r5 Thanks and sorry for the few information. I'm relatively new to linux and KDE and don't wanna spam the forum. Please aks me for the missing stuff. |
Manager
|
might be a corrupt rc file
can you create and test a new user to see if it's your config or a KDE issue also try resetting plasma, as current config will be backed up you'll be able to revert
ps - welcome |
Registered Member
|
Hello and thanks for the reply.
Creating a new user meant to copy at least all necessary desktop and plasma-config-files back to the new user. Same problem here: The plasma-config files are altered when KDE starts. I also moved the config files and, of course, a new clean config is created, producing me a new clean desktop. I already mentioned that i manually deleted the config file (forgot to delte the plasma-desktoprc file, so thanks for the hint) with the same result. It seems like there is no difference between my original user and a new one. I noticed another cruel behavior: Using my original user and copying the configs back as root, forgetting to set write permissions for the user, i get the following result:
A Message Box in front of a black screen tells me (in german) that the config file can't be written. After confirming the message box, kdeinit4 resumes and - *tadaa* - shows my old four desktops with all my icons and stuff. The message box is crated by plasma-desktop and not by kdeinit. This behavior is clearly reproduceable again and again. It seems like there are two steps running within the plasma-desktop process: 1) Starting a parser that reads the config file, checks it (desperately need more debug info here!) and writes it back to the config. --> Fails parsing? 2) Starting a (or the same) parser (again) to read out the (changed) config. --> Succeeds parsing Once again I want to mention that in a very few cases the error didn't occur when booting my original setup. Most times the error occured but some few times it didn't. Wouldn't a parser be accurate instead of behaving like "Oh, not you again. Okay, this time i'll let you pass" every 20th reboot? I still guess that it's a race condition while reading and parsing the config file. As I'm running a live system residing in RAM, everything is processed much faster than on an installed system. I was not able to reproduce this error on a permanently installed system with my user (KDE plus Plasma) setup. |
Administrator
|
Can you check the status of "kactivitymanagerd" process? If you click on the Plasma toolbox in the upper right corner and select "Activities", how many are presented to you in the bar that appears at the bottom of the screen? (It should be just one).
"Violence is the last refuge of the incompetent."
Plasma FAQ maintainer - Plasma programming with Python |
Registered Member
|
The kactivitymanagerd is up and running.
I got one Item in the mentioned list and did not add any new "Activitiy" by myself. Seems to be fine so far. |
Administrator
|
Is Nepomuk enabled or disabled on your system? Many developers run with Nepomuk enabled (but disk indexing disabled) which means the Activities features of KDE may not be performing as expected...
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
Registered Member
|
Nepumuk is enabled.
Since I'm not familiar with this part, how can I check if disk indexing is enabled? And would I require Nepomuk running on my system (may i just deactivate it)? I guess it has something to do with the nepomukserverrc and nepomukstrigirc files, right?
I continued messing with the read-only plasma-desktop* files: As I wrote, a kdialog pops up when plasma-desktop can't write the config files - so /usr/bin/kdialog is being executed. I can replace the kdialog binary by a simple shell script. When I write "sleep 1" into the script, it is executed, waits one second and then plasma-desktop continues. That way, the desktop is initializes as i want it to (all icons and stuff present). When I leave the script blank (no sleep), it is executed, doen't wait and plasma-desktop immediately gets back to work (no delay). That way, the desktop is messed again (initializes as default desktop without icons and stuff). I know I'm bugging with it, but that also seems to point to some race condition problem in plasma-desktop. Thank you all for your Replies. I might not be able to respond until next monday. |
Administrator
|
The race condition here very well could be the startup of kactivitymanagerd or Nepomuk, either of which would explain why this keeps happening to you. Are these "warm" or "cold" logins, and is there anything special about the I/O component of your system - this race condition does not normally occur.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
Administrator
|
There used to be a race indeed, but it should have been fixed in 4.10.
"Violence is the last refuge of the incompetent."
Plasma FAQ maintainer - Plasma programming with Python |
Registered Member
|
Thanks for the replies.
It occurs at warm and at cold logins but it seems that the error occurs more likely at "warm" logins. Well, as i said, the system is a live system that is completely loaded into RAM. This speeds up a lot of things. If the config is read before plasma gathered all hardware information (e.g. current resolution) it might stumble upon several config settings for the same config sections. The race condition might be fixed but maybe not for very fast systems like that(?) Furthermore I'm using a unionfs filesystem overlay for /home which could also affect the behavior of writing/reading the configs (Is there a file lock mechanism implemented in fuse as like in ext file systems?). The rest of the system is just standard client config and hardware without special components - and as i also said, the error does not occur with the same "image" installed to and loaded from HDD on the same hardware type. But unionfs is used there, too. Can't guess any other difference than the "live system speed". |
Administrator
|
I wonder if the near-instant access in RAM is by itself creating this race, if this does not occur when loading from disk. Is the system fully booted up and already offloaded to the RAM disk by the moment you log in?
"Violence is the last refuge of the incompetent."
Plasma FAQ maintainer - Plasma programming with Python |
Registered Member
|
Right.
There is practically no hard drive present at KDE boot time. Everything is loaded straight out of RAM and no data/libraries are "post-loaded" via network/HDD (comparable to the "toram" Option of Knoppix). |
Administrator
|
I don't think this setup was throroughly tested by developers: you may want to file a bug on bugs.kde.org if you haven't already because this issue may be a sympthom of some defect in the code which should be fixed.
"Violence is the last refuge of the incompetent."
Plasma FAQ maintainer - Plasma programming with Python |
Registered Member
|
Thanks to all of you for your suggestions.
I created a bug https://bugs.kde.org/show_bug.cgi?id=323211 for this one. You may want to close this forum thread now. |
Registered users: bartoloni, Bing [Bot], Google [Bot], Yahoo [Bot]