Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0) OS: Linux If I change the plasma desktop background, it creates a plasma-appletsrs config file that causes the panel to be missing the next time I start plasma. Steps to reproduce: 1) Right-click on desktop and click "Configure Desktop" 2) Select a wallpaper and click OK 3) A config file ~/.kde4/share/config/plasma-appletsrs will be created 4) Kill plasma and restart it. 5) Observe panel is missing. (You can kill and restart plasma several times and it'll stay that way). 6) Delete ~/.kde4/share/config/plasma-appletsrs 7) Kill and restart plasma again. The panel should come back The following debug output is probably relevant: <unknown program name>(14050)/ checkComposite: Plasma has an argb visual 0x805d6c8 27262977 <unknown program name>(14050)/ checkComposite: Plasma can use COMPOSITE for effects on 0x80578a0 plasma(14054) PlasmaApp::PlasmaApp: Setting the pixmap cache size to 10330 kilobytes plasma(14054) Plasma::Corona::addContainment: loading of containment "" failed. plasma(14054)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/home/aidan/.kde4/ cache-yarrow/ksycoca4" findServiceByDesktopPath: not found plasma(14054) Plasma::LayoutItem::setLayout: layout removed from under us. expect crashes plasma(14054) DefaultDesktop::reloadConfig: Default would be "/home/aidan/kde4/share/wallpapers/EOS/contents/i mages/1920x1200.jpg" plasma(14054) DefaultDesktop::reloadConfig: but we're loading "/home/aidan/kde4/share/wallpapers/EOS/contents/ images/1920x1200.jpg" instead plasma(14054) PlasmaApp::createPanels: Containment name: "Unknown Applet" | type 2 | screen: -1 | geometry: QR ectF(0,0 200x20) | zValue: 100 plasma(14054) PlasmaApp::createPanels: Containment name: "Desktop" | type 0 | screen: 0 | geometry: QRectF(0,0 1024x768) | zValue: 100
i've set the background wallpaper several times in the last weeks and not observed this. can you attach the offending plasma-appletsrc file for inspection? also, this step concerns me: 4) Kill plasma and restart it. how did you "kill" it? with "kill -9" or some such? if so, all bets are off. we do a delayed saving of the config file to compress disk activity causing events and save on clean exit. forceably killing plasma (or most apps, for that matter) leaves no guarantee that its data will remain in a known-good state.
Created attachment 22852 [details] Bad plasma-appletsrc
How odd... it hasn't saved anything but the desktop containment. If you change the wallpaper and call "kquitapp plasma", (a) does it still do the same thing, and (b) what debug output do you get as it quits?
Looks like my description of the bug was incomplete, sorry. If I have no plasma-appletsrc, it writes out an incomplete one like the one attached. It does write out a correct one if exited properly (such as by sending a quit message over dbus - which is, I think, what kquitapp does - or presumably by logging out). However, it doesn't write out a new, correct config file if it's killed using SIGTERM (or of course if it crashes at some point), so the incomplete one stays and causes the missing panel. This issue doesn't seem to occur if a correct plasma-appletsrc already exists, which may be why you've never encountered it. It's also doesn't appear to be a simple truncation of the file, and it doesn't even write the full information for the desktop containment - if I attach the full version, you'll see what I mean.
Created attachment 22853 [details] Good plasma-appletsrc
Corona::loadDefaultSetup() already schedules a config sync when it loads the setup for the first time. This was added in r755616. What revision are you using?
> if it's killed using SIGTERM (or of course if it crashes at some point) right, and this is explicitly unsupported behaviour. the problem is really triggered because the desktop containment was previously calling sync() directly which would cause a partial write out. this has been fixed in svn. still, kill -9'ing plasma at the wrong time will leave you with an incomplete config. so don't do that. that's why we have kquitapp. terminating a process at a random point in its execution will create undefined behaviour without lots of checkpointing overhead that is simply not acceptable for a program like plasma (though it's justifiable for, for instance, an RDBMS)
And what about using CTRL+ALT+Backspace to restart a X server? Is that unsupported behaviour. What happens when you have problems with your X server (for example, bug in kwin leaves you without visualization in your dekstop), you hit CTRL+ALT+Backspace to restart the session and, Bang! no panel! (in fact i am reading this bug report because i was going to report the missing panel) I don't think that's not a reasonable behaviour for plasma... but just my two cents.
ehm... [...]Is that unsupported behaviour?[...] [...]I Think that's not a reasonable behaviour for plasma. [...] Sorry for the previous post. 'First post' addiction in Slashdot have gone too far for me and it seems i can't re-read a post before hitting 'commit'. sorry :(
interupting plasma by killing it is indeed unreasonable behaviour. trying to safely do something as complex as saving configuration status on a caught signal is not worth it. the only way to work around this is to save constantly to disk on every possible change. this is simply not rational for reasons already noted. while apps such as kwrite, kword and kmail all do temp file saving as you write, it is also possible to cause all of them to also lose data in such situations. so plasma is not unique here. i'd also note that killing the app can at times be a perfect way of preventing a screwed up config from being written to disk =)
I find that a reasonable compromise in these situations is to periodically flushing the config to disk, perhaps every 10 minutes or so. It prevents the "I have been configuring plasma all day, and now it crashed, and now I have to do it all over again" Just my 0.02€, though.
> a reasonable compromise in these situations is to periodically > flushing the config to disk, perhaps every 10 minutes or so and wake a sleeping cpu for no good reason? bah. no, we have a signal that components can emit when they need something to be saved and we schedule a save 2 minutes thence. it's completely on-demand but with 2 minute intervals. the whole reason this didn't work out is because the guys working DefaultDesktop didn't exactly listen when i said, "don't use sync() directrly" and i didn't notice that they'd committed such a thing. if instead they had used the signal, this would not even be an issue.
Well, the solution in #12 is a variant on my humble suggestion, just much better :)