After shutting down from within an xfce session, in many cases (not always), the mount plugin configuration file is gone: .config/xfce4/panel/ no longer contains any xfce4-mount-plugin-*.rc, only some xfce4-mount-plugin-32.rc.*.tmp, all of size zero. On the next startup, the plugin creates a new .rc file with default settings (very different from my settings). Other plugins are not affected, their configuration is not changed by reboots.
Problem still exists: After reboot (not every reboot, only now and then), the mount plugin ist started with the default configuration instead of the configuration it had in the last session. All my settings are lost.
Does the problem also exist with other plugins? There are two things to consider: When shutting down, all the plugins obtain a hook call to store their settings. This one might be missing. But then, the old settings from last time shall be applied at the next bootup. When being started, any plugin obtains an ID from the panel and the path to the settings (file). In such a case, it would be interesting to know the ID of the stored file, the contents of the stored file and the ID of the running instance. Maybe you are also running two different instances and that causes the problems? $ ls -la ~/.config/xfce4/panel/xfce4-mount* $ ps -aux | grep xfce4-mount What happens when then restarting the panel manually again via $ xfce4-panel -r ? Again no config loaded, or old config loaded again? Does $ tail -f .xsession-errors deliver any interesting output (or did the failing bootup, i.e., $ cat .xsession-errors | grep mount)? Btw., which versions are you using?
(In reply to Fabian Nowak from comment #2) > Does the problem also exist with other plugins? There are two things to > consider: When shutting down, all the plugins obtain a hook call to store > their settings. This one might be missing. But then, the old settings from > last time shall be applied at the next bootup. When being started, any > plugin obtains an ID from the panel and the path to the settings (file). In > such a case, it would be interesting to know the ID of the stored file, the > contents of the stored file and the ID of the running instance. Maybe you > are also running two different instances and that causes the problems? No, mount is the only plugin suffering from the problem. And it is a random problem: It doesn't happen at every restart and can't be reproduced at will, but happens only once in 20 or 30 restarts. Must be some kind of race condition, perhaps X is shut down before the plugin saved its state or something like that. > $ ls -la ~/.config/xfce4/panel/xfce4-mount* -rw------- 1 kk kk 345 Aug 18 09:37 /home/kk/.config/xfce4/panel/xfce4-mount-plugin-32.rc -rw------- 1 kk kk 0 Aug 12 16:19 /home/kk/.config/xfce4/panel/xfce4-mount-plugin-32.rc.378.tmp -rw------- 1 kk kk 0 May 12 22:38 /home/kk/.config/xfce4/panel/xfce4-mount-plugin-32.rc.393.tmp Perhaps the old zero-sized files are from moments when the problem happened? > $ ps -aux | grep xfce4-mount kk 392 0.0 0.0 391360 27056 tty1 Sl 09:17 0:00 /usr/lib64/xfce4/panel/wrapper-2.0 /usr/lib64/xfce4/panel/plugins/libmount.so 32 16777227 xfce4-mount-plugin > What happens when then restarting the panel manually again via > > $ xfce4-panel -r > > ? Again no config loaded, or old config loaded again? Does Tried several times. Lots of other error messages, but nothing related to mount, and mount always restarted correctly (with my settings). > $ tail -f .xsession-errors > > deliver any interesting output (or did the failing bootup, i.e., $ cat > .xsession-errors | grep mount)? I've only .xinitrc.log, no .xsession-errors, and it contains nothing I'd relate to mount. I log into a text console and start my X from there, no X display manager starting an X session. > Btw., which versions are you using? 1.1.3
Happened twice in the last five days. For both cases, a new (and empty) file .config/xfce4/panel/xfce4-mount-plugin-32.rc.xxx.tmp (with xxx being some number) was left in .config/xfce4/panel/ , so these files and the problem are definitely related. Time & date of those files are those of the corresponding system shutdowns. Is there some copy or rewrite operation of such files during shutdown which could cause the main configuration file to get lost? Could this rename, copy or whatever be subject to race conditions? Is it possible that the plugin process gets killed before the operation is completed?
What a pity, the sensors plugin also has some issues with saving the settings. Maybe the xfce4-panel changed a little bit. Are you running a machine with lots of processor cores? As suggested in another bug report, I am currently setting up an arch linux; maybe the distro really behaves differently to my debian. As you mentioned that no other plugins suffer from this problem, I can investigate in their code, what they do differently and how they adapted to changes in the panel.
(In reply to Fabian Nowak from comment #5) > What a pity, the sensors plugin also has some issues with saving the > settings. Maybe the xfce4-panel changed a little bit. Are you running a > machine with lots of processor cores? As suggested in another bug report, I 4 processor cores with HT here, so 8 cores in linux. > am currently setting up an arch linux; maybe the distro really behaves > differently to my debian. As you mentioned that no other plugins suffer from I'm using gentoo linux, but with systemd for startup and shutdown, not with gentoo's openrc. And I don't use a display manager for logging in, but log into the text console (vt0) and start X and xfce with startxfce from the command line. What's your startup/shutdown system? I still suspect that perhaps the panel / the plugin get's killed on shutdown while it is still manipulating config files, saving session or whatever. > this problem, I can investigate in their code, what they do differently and > how they adapted to changes in the panel.
Ok, thanks for the quick reply. I have 2 cores, Lightdm and systemd. Your suspection sounds somewhat reasonable and plausible to me as well.
* It happened again, and again, a .tmp file of size 0 was left in the config dir. However, this time, there also was a .tmp file of size 0 from the netload plugin. But, differing from the mount plugin, the netload plugin did not "forget" its configuration: In spite of the .tmp file, the netload config was fine (not the default, but what I've set before). So they definitely behave differently. * About terminating too early: What happens when the X server goes away too early during shutdown? Does this immediately terminate the panel and the plugins (even if they have not finished their cleanup yet), or do they complete their cleanup and finish cleanly even without X running?
Fabian referenced this bugreport in commit 39c3ab4db35cd3efdb6eec2d8ec04fa0edb6ccdc Fix bug 13624 by not trying to save when closing the plugin, but already and only when closing the settings dialog https://git.xfce.org/panel-plugins/xfce4-mount-plugin/commit?id=39c3ab4db35cd3efdb6eec2d8ec04fa0edb6ccdc
Some years ago, the plugin developers and maintainers were urged to listen to the "save" event despite saving the settings at dialog closing because otherwise the settings wouldn' t be saved. This code is/was still in the mount and sensors plugin maintained by me. I removed it with commits 1489959..ae94a87 and 2734131..00538c7. You might want to try the newest code in the Git repository. I can't tell what happens when shutting down too fast. I can only guess that there happens somewhere an exception by whatever component involved, so that the whole shutdown/logout process stops immediately. Normally, in a good world, the X environment should wait for the Xfce desktop environment and the panel and all its plugins to terminate. However, on my system the panel isn't a child process of the X server. Thus, as suggested by you, it might really happen that the X server terminates before panel does, thereby leading to crashes of the running plugins because their X resource vanishes. Is this a sound explanation? You might want to ask on the user or developer mailing list for further assistance.