You are not logged in.
Hello,
i'm trying to build an custom desktop configuration based on Debian/XFCE (4.14).
I have set XDG_CONFIG_DIR and XDG_DATA_DIR in /etc/XSessions.d/scriptname
but xfconfd doesn't load the config from these XDG-Locations.
With "strace xconfd" i have found that xfconfd loads only the Configuration from the user-home and
from /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/....
How can i order xfconfd that he load default Config from another directory like /etc/xdg/DISTRIBUTIONNAME/xfce4/xfconf/xfce-perchannel-xml/....?
The setting of die XDG-Variables doesn't work with xfconfd. Why?
Thank you!
Offline
Hello and welcome.
I have set XDG_CONFIG_DIR ...
Checking to see if this is a typo - it should be XDG_CONFIG_DIRS.
If not a typo, after you log in, what is XDG_CONFIG_DIRS set to?
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
Hello and welcome.
mastro wrote:I have set XDG_CONFIG_DIR ...
Checking to see if this is a typo - it should be XDG_CONFIG_DIRS.
If not a typo, after you log in, what is XDG_CONFIG_DIRS set to?
Sure! I have used XDG_CONFIG_DIRS. My Typo-Error ist in the Forum-Post.
XDG_CONFIG_DIRS=/etc/xdg/xlinux:/etc/xdg
XDG_DATA_DIRS=/usr/share/xlinux:/usr/share/xfce4:/usr/local/share ...
"xlinux" is the name for my testing.
I have set these variables with export in an /etc/X11/Xsession.d-Script.
If I copy the xfce-perchannel-xml-Files to /etc/xdg/xfce4/ everything works fine.
In the XML-Files I would set few Default Settings. Panelposition and Plugins works.
But the Setting from "thunar.xml", "xfce4-session.xml" and "xfce4-desktop.xml" will not be loaded.
Offline
XDG_CONFIG_DIRS=/etc/xdg/xlinux:/etc/xdg
XDG_DATA_DIRS=/usr/share/xlinux:/usr/share/xfce4:/usr/local/share ...
This looks right.
I have set these variables with export in an /etc/X11/Xsession.d-Script.
If I copy the xfce-perchannel-xml-Files to /etc/xdg/xfce4/ everything works fine.
These files are executed based on order of filename. What order is it in? Does it help if you move it up in the order (maybe something the new user xfce generation is done before this script is executed (before your new XDG_CONFIG_DIRS is set).
Another option is to use /etc/skel for your default files. That way, when a new user is created, it will use the files in that directory as the original set of configuration files.
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
These files are executed based on order of filename. What order is it in? Does it help if you move it up in the order (maybe something the new user xfce generation is done before this script is executed (before your new XDG_CONFIG_DIRS is set).
I'm not sure what you mean.
Do you mean the Order of paths in the variable XDG_CONFIG_DIRS, or that the name "xlinux" comes after "xfce"?
The names of the XML-Files are static and not to change.
Or:
Do you mean the that xfconfd are loaded by an Xsession.d-Script before I set the variable XDG_CONFIG_DIRS?
Another option is to use /etc/skel for your default files. That way, when a new user is created, it will use the files in that directory as the original set of configuration files.
I know this solution, but this solution only affected to new users and provide sometimes error while installation because the files are provided by more than one DEB-Package.
A few years ago, i have a DEB-Postinstall-Script used which copy the Files to /etc/xdg/xfce4, but these solution is dirty.
I think it is an error that xfconfd doesn't load all XML-Configuration files in order auf XDG_CONFIG_DIRS.
But who can say that i'm wrong thinking? What is my mistake?
Offline
These files are executed based on order of filename. What order is it in? Does it help if you move it up in the order (maybe something the new user xfce generation is done before this script is executed (before your new XDG_CONFIG_DIRS is set).
I'm not sure what you mean.
Do you mean the Order of paths in the variable XDG_CONFIG_DIRS, or that the name "xlinux" comes after "xfce"?The names of the XML-Files are static and not to change.
Or:
Do you mean the that xfconfd are loaded by an Xsession.d-Script before I set the variable XDG_CONFIG_DIRS?
If you look at the contents of /etc/X11/Xsession.d, you'll notice that all of the files are prefixed with a number. This indicates the order that the file is processed. I don't use Debian so I'm not sure of the specifics, but maybe one of those scripts initiates the process of copying over the config files before you set your new XDG_CONFIG_DIRS variable.
Another option is to use /etc/skel for your default files. That way, when a new user is created, it will use the files in that directory as the original set of configuration files.
I know this solution, but this solution only affected to new users and provide sometimes error while installation because the files are provided by more than one DEB-Package.
A few years ago, i have a DEB-Postinstall-Script used which copy the Files to /etc/xdg/xfce4, but these solution is dirty.I think it is an error that xfconfd doesn't load all XML-Configuration files in order auf XDG_CONFIG_DIRS.
But who can say that i'm wrong thinking? What is my mistake?
This is an interesting comment. When Xfce is first started for a new user, it looks into ~/.config/xfce4 for config files. If it doesn't find them, it reaches back into the XDG_CONFIG_DIRS path to look for those files. Once found, it copies them to the user's ~/.config/xfce4 directory, and from then on in, it uses those. Any changes to the files in /etc/xdg or /etc/xlinux/xdg won't be processed if the files are found in ~/.config/xfce4. In fact, once a new user is created, that account will only ever use the files in ~/.config/xfce4 (unless you delete them), so to change settings for existing users, you need to individually change those config files.
I'm not sure how you were copying files to /etc/xdg/xfce4 that were then being processed by user accounts that already had those files in ~/.config/xfce4. Maybe Debian does something different?
Also it is odd that files you place in /etc/skel are being overwritten. The purpose of /etc/skel is for you to put specific custom files in. See https://www.debian.org/doc/manuals/debi … ts.en.html.
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
Xsession.d-Scripts)
I know that these Script are run by numbers. I set XDG_CONFIG_DIRS in the last script.
I'm sure that xfconfd is loaded after these Scripts. Only DBUS will be started before.
For your information)
1. At creation of new user will be /etc/skel copied to the new user homedir.
2. At Login loads xfconfd the configuration from ~/.config/xfce4
3. XML-Files which not exists, will be loaded from /etc/xdg/xfce4
At first configurationchange from the User saves xfconfd the XML-Files to the Userhome (Point 2), not before!.
If i want reset the User-Settings: stop xfconfd and delete ~/.config/xfce4/xfconf/xfce-perchannel-xml/.
To point 3 is the Default-Settings from Distribution. This is also explaind in the documentation of XFCE/Debian.
There is also explaind the XDG-Vars. But if I change the XDG-Variables nothing changed at working from xfconfd.
Offline
I've downloaded the debian ISO and spent some time looking at it, and I'm hitting the same wall as you. It isn't working for me either. I'm certain this used to work.
I've been looking at how xubuntu does this (they use an /etc/xdg/xdg-xubuntu base directory), but I haven't been able to figure it out yet . Perhaps you can send an email to the xfce4-dev mailing list to see if a developer can shed some light on this.
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
Wow, so this is what's happening? Finally some in-depth info on this. I was trying for the longest time figure out from where Xfce is reading the values at login time, because doesn't seem to be from the XML files.
Just to give some perspective, for the past 4 years I've been using Xubuntu 16.04 and manually replacing the XML files and then logoff/login restored my previous values for a Live-Session. All my Xfce4 settings could be easily restored like that, no hassle.
Then, I buy new hardware and I need to change distro for more compatibility. So far I've been trying latest Manjaro Xfce and latest MX-Linux AHS build from November-2020
I've been unable to restore Xfce4 settings on both, Manjaro (based on Arch) and MX (based on Debian).
Sometimes, logging Off and logging back In leaves me with default mouse settings even, I have to set them up again.
Keyboard layouts, keyboard shortcuts, not even panel plugin settings are being saved.
This is annoying problem that must be tracked and solved as soon as possible because it will affect all distributions that use Xfce.
Thanks for your detailed report, german friend, I will try to place a copy of my XML files on /etc/xdg and the other paths mentioned, to see if I can find ways to remedy this. Endless hours WASTED on having to deal with this.
Is there a way, perhaps, that I could purposely downgrade my Xfce4 version in order to try if this works once again like it did on 16.04? Is it possible to know at what point in time changes to this underlying "Session saving" procedures had been made?
Also, I deeply miss the buttons "Save Backup of the Panel" (which was available at Xubuntu 16.04) and to save more than one session (as mentioned above) So much hassle for no reason whatsoever.
Last edited by FeelingShred (2020-12-02 01:10:54)
Offline
I even tried creating a new user to use on the Live-Session, but this seems to aggravate the problems even further. I made all my xfce changes manually from scratch, logged off, when logging back in all changes were missing, there was a stock "fresh" Xfce desktop, nothing to do with what I have done before logging off (and yes, of course I pressed the button Save Session at logoff screen, like I always do)
Is this something specific to Live Sessions? Or do this also happen on full disk installs?
I have seen reports of problems like these on Manjaro forums, lots of unanswered threads (which lead me to believe that the distro maintainers know about this bug) and I don't believe majority of these people are all using Live Sessions.
Question #2) I see that both in Manjaro as in MX Linux, there's a bunch of autostart scripts, both in ~/.config/ as in /etc/xdg/autostart/
Could these autostart scripts be messing with not storing settings correctly?
I remember my Xubuntu 16.04 Live Sessions having no autostart scripts whatsoever, the directory was empty.
Last edited by FeelingShred (2020-12-02 01:19:51)
Offline
A few years ago, i have a DEB-Postinstall-Script used which copy the Files to /etc/xdg/xfce4, but these solution is dirty.
I think we are in the same boat, I think we want the same thing. In my case, I depend on Live-Sessions and deploying multiple machines, custom ISO's made by JLiveCD (chroot method)
I have (or well, I had, Past tense now...) startup scripts to initialize the system (re-load previous session configs) and also a script to make backup of the current session.
Could you share a bit of how your Post-Install script there looks or looked? Just to compare with mine.
Below is the portion of my Startup script which was responsible for re-loading all the Xfce Session settings in a Live-Session:
sudo killall xfce4-panel
sleep 1
sudo rm -r /home/username/.config/xfce4
/bin/cp -ar /home/username/.config/Backups/xfce4 "/home/username/.config/"
/bin/cp -ar /home/username/.config/Backups/xfce4/* "/home/username/.config/xfce4"
/bin/cp -ar /home/username/.config/Backups/xfce4/panel/* "/home/username/.config/xfce4/panel"
/bin/cp -ar /home/username/.config/Backups/xfce4/xfconf/xfce-perchannel-xml/* "/home/username/.config/xfce4/xfconf/xfce-perchannel-xml"
# sudo rm -r /home/username/.config/gtk-3.0
/bin/cp -ar /home/username/.config/Backups/gtk-3.0/* "/home/username/.config/gtk-3.0"
# sudo rm -r /home/username/.config/gtk-2.0
/bin/cp -ar /home/username/.config/Backups/gtk-2.0/* "/home/username/.config/gtk-2.0"
# sudo rm -r /home/username/.psensor
/bin/cp -ar /home/username/.config/Backups/.psensor/* "/home/username/.psensor"
# sudo rm -r /home/username/.cache/sessions
/bin/cp -ar /home/username/.config/Backups/sessions/* "/home/username/.cache/sessions"
echo "Xfce4 Session OK... Logoff and Log back In to apply changes..."
sleep 1
nohup xfce4-panel &
There were still a few workarounds needed with this method: (reminder... this was on Xubuntu 16.04)
1) Battery/Power settings not always restored, so I would change suspend timeouts, log off and log back in, twice, to guarantee that the new values were saved. This was relatively hassle-free and very quick to do.
2) Before running the script, I had to manually add all the panel plugins that I wanted, AND THEN the script would apply the individual settings to each one of them, after a logoff.
All in all, this script saved TONS of hours, which sadly seems to not be possible anymore. Isn't productivity one of the paramount reasons why we use Linux in the first place? Please guys let's give attention to this and try to solve it the sooner possible. There are two different guys here with this same symptons, the time to do testings is now, let's take advantage of it.
Offline
Sorry my english is not very good...., but I try....
I have made a custom livecd for my work, but i only use this for my customers, if they computers death.
I'm not sure how your livesystem works.
My Install-CD make this:
Install DEB with postinst-File below:
#!/bin/bash
set +e
set_xfce_defaults() {
sh /opt/XLinux/update_default_config.sh
}
case "$1" in
configure)
set_xfce_defaults
;;
triggered)
set_xfce_defaults
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 0
;;
esac
#DEBHELPER#
Content of /opt/XLinux/update_default_config.sh:
#!/usr/bin/bash
cp -r /opt/XLinux/xfce-desktop-settings/* /etc/ 2>/dev/null
if [ -d /opt/XLinux/xfce-design ]; then
cp -r /opt/XLinux/xfce-design/* /etc/ 2>/dev/null
fi
rm -f /usr/share/applications/xfce4-terminal-settings.desktop 2>/dev/null
rm -f /usr/share/applications/thunar-settings.desktop 2>/dev/null
rm -f /usr/share/applications/Thunar-folders-handler.desktop 2>/dev/null
rm -f /usr/share/applications/Thunar.desktop 2>/dev/null
rm -f /usr/share/applications/system-config-printer.desktop 2>/dev/null
rm -f /usr/share/applications/icedtea-* 2>/dev/null
rm -f /usr/share/applications/terminal-as-root.desktop >> /dev/null 2>&1
rm -f /usr/share/applications/thunar-as-root.desktop >> /dev/null 2>&1
sed -i 's/^Categories=.*/Categories=Settings;X-XFCE-SettingsDialog;X-XFCE-PersonalSettings;/' /usr/share/applications/mugshot.desktop 2>/dev/null
I have in /opt/XLinux/xfce-design/ my file-structure of /etc/xdg/xfce4 and /etc/skel, but only these file which I have changed.
At install of Linux wil be user creation after DEB-install. At first login of user is /etc/skel automaticly copied to the user home and /etc/xdg/xfce4 will be readed by xconfd as default settings.
Your soulution have the Problem that xfce4-panel requests the settings by xfconfd. xfconfd normally load the settings at login of user, but I have seen that sometimes xfcond not reloaded at logoff/loin. If I restart the computer or kill xfconfd with a terminal-session (ssh) xfconfd loads the settings always correct.
Offline
(you can ignore this post, I was typing while he wrote a reply... this is a mere tracking down of steps in search for clues to what's going on, if that's relevant to anything...)
OK, look what an interesting finding, for Xubuntu 16.04 there's a package called
xubuntu-live-settings
apparently responsible for creating the live-session 1st boot environment. Like Mastro pointed above, it seems like Xubuntu was also copying the initial data from /etc/xdg/
mkdir -p /root/home/$USERNAME/.config
cp -R /root/etc/xdg/xdg-xubuntu/xfce4 /root/home/$USERNAME/.config
chroot /root chown -R $USERNAME:$USERNAME /home/$USERNAME/.config
These below seems to be the specific versions of the xfce4 packages that I was using and the XML files for recovering previous session was working fine in that specific version.
Is that a way to roll back to these versions to test them out?
Source: https://distrowatch.com/table.php?distr … 04#pkglist
Xubuntu 16.04
• xfce4-notifyd 0.2.4-3ubuntu1
• xfce4-panel 4.12.0-3ubuntu2
• xfce4-session 4.12.1-3ubuntu1
• xfce4-settings 4.12.0-2ubuntu1
• xfconf 4.12.0-2
• xfdesktop4 4.12.3-2ubuntu1
• xfdesktop4-data 4.12.3-2ubuntu1
• xfpanel-switch 1.0.4-0ubuntu1
• xfwm4 4.12.3-1ubuntu2
• xubuntu-default-settings 16.04.6
• xubuntu-live-settings 16.04.6
And this are the versions used on Manjaro, which I had been using for a full month and wasn't able to find a definitive solution for this yet, besides perhaps making all my settings to xfce from the command line at startup time, but that would not be necessary if Xfce worked as intended in the first place (as it worked in the past, to repeat myself one more time)
Manjaro 20.1 (2020)
• xfce4-notifyd 0.6.2-2
• xfce4-panel 4.14.4-1
• xfce4-session 4.14.2-2
• xfce4-settings 4.14.3-1
• xfconf 4.14.3-1
• xfdesktop 4.14.2-2
• xfwm4 4.14.5-1
• manjaro-hotfixes 2018.08-6
• manjaro-settings-manager 0.5.6-10
• manjaro-settings-manager-kcm 0.5.6-10
• manjaro-settings-manager-knotifier 0.5.6-10
• manjaro-settings-manager-notifier 0.5.6-10
• manjaro-system 20200906-1
• manjaro-xfce-settings 20200811-1
I browsed the Manjaro files above in search of any clues, but nothing specific seems to exist there, just a bunch of references to /etc/skel/, default xfce files, not anything customized from what I was able to see.
Seems like this is an issue coming directly from the Xfce source code itself, not from config files.
I was trying to track down every instance of the source code where xfconf gets referenced a few days ago, but it seems like it uses a bunch of gpointers and g_chars for storing values, I'm not a coder myself so I don't know from where specifically these values are being read from and to where they are being stored to. The most important part seems to be: What in the source code is causing the XML files to be ignored at login time? Shouldn't XML files inside of ~/.config/xfce4/ be read at every single login? Values are being read from somewhere else, and as soon as the user reboots these changes are lost. (but the XML files are always up to date on disk, I don't get it... they are being SAVED, but they are not being READ)
Last edited by FeelingShred (2020-12-02 09:32:25)
Offline
but I have seen that sometimes xfcond not reloaded at logoff/loin.
If I restart the computer or kill xfconfd with a terminal-session (ssh) xfconfd loads the settings always correct.
OK, thanks so much for this.
We have clues to follow now.
Just explain me one thing:
Do I need to kill xfconfd after I have logged in? Or kill it before logging off? Is there a specific order of events?
Offline
I havn't tryed.
I have make a logoff then login, and have seen that changed settings not loaded.
So I have logoff, kill xfconfd (over ssh) and then login.
But this thread is not analysed from me!
Offline
Oh, ok, so I have to kill xfconfd
while I am in Login Manager screen (before logging in) by pressing Ctrl Alt F2
Interesting. Will try it.
Offline
OK, I tried different methods, new problems appear now.
I had the MX Linux live session going, setting up all my apps, the final step would be to create a snapshot of it, to turn it into a bootable ISO later on.
1) I logout, go to tty terminal, kill xfconfd (it was not running), kill xfsettingsd, log back in (live session user)
2) Everything seems to work OK, except I can't disconnect/connect from the network (request failed: not authorized) and I can't change brightness of the laptop monitor
3) I try copying /etc/xdg/autostart to /home/.config/autostart, log off, kill xfsettingsd xfconfd (none of them were running), same thing happens, can't change networks, can't change brightness, and now this time also the sound volume keyboard hotkeys also don't work
4) I checked /etc/skel directory, there's nothing different there, autostart contents are the same as user configs
I'm clueless to what's going on.
Is this a problem with Xfce in general or the way this MX system is built? Or both?
How does 1st live-session log in works but logoff breaks it? Systemd?
Tired of having to deal with pitiful bullshit like this. Searching a bit further, it seems like this Xfce bug is around since 2012 or so, there are blog posts from that period. So fucking dumb.
Offline
3) I try copying /etc/xdg/autostart to /home/.config/autostart, log off, kill xfsettingsd xfconfd (none of them were running), same thing happens, can't change networks, can't change brightness, and now this time also the sound volume keyboard hotkeys also don't work
I think /etc/xdg/autostart ist wrong. Correct should be /etc/xdg/xfce4/autostart
Offline
that`s the path, I`m just not typing all that crap here, you see... the paths are the same... not only it did not work, as my entire system broke, couldn`t even startx from Root user tty, I had to reboot the whole thing, all the progress done in the live session gone
I`ve got messages like System not able to find something something template in /etc/xdg/ could not initialize X session... and it also said "possibly xfconfd is not runnning"
Are you sure xfconfd and xfsettingsd can be safely killed?
Ever had permission or systemd problems like that when you needed to change live-session settings to create an ISO?
Offline
Back from MX to manjaro... tried some different methods found on the net... Still not working as it's supposed to.
Method 1 - rename /.config/xfce4 and see if you can log back into a new fresh session, with your panel settings and such:
1) (fresh live-session) Change my panel, mouse, keyboard and Thunar settings. Delete contents of /etc/xdg/xfce4 (just leave there the init file and the init script)
2) copy contents of /home/user/.config/xfce4 (everything CTRL+A) to /etc/xdg/xfce4 and also to /etc/skel/.config/xfce4
3) Log out
mv /home/user/.config/xfce4 /home/user/.config/xfce4.bak
4) Log back in. OK everything works until here, /.config/xfce4/ contents are re-populated with my settings, except one specific plugin (Netload) and taskmanager settings do not restore (have to set them up again)
5) Observation: I noticed that xfconf directory does not get re-populated. This is the bug. It's reading panel configs from somewhere else, and it's not saving in the /home/.config path as supposed to.
Method 2 - create new user, to make use of the settings stored in /etc/skel/
1) Create new user, log off and log into new user
2) Does not work. It says no working session file could be found, doesn't let me log in into the desktop
Method 3 - still using the live-session user, but try creating a new session (Always display chooser at logon)
1) The new session is created, settings are inherited again, but the same ones are missing: Netload plugin and taskmanager preferences (these reset to defaults)
So basically Xfce is broken on any system that's not Xubuntu itself?
But Xubuntu doesn't offer support to the latest hardware, we are stuck using other distros.
Offline
Succesfully booted custom ISO created with Chroot.
1) Replaced files (not entire directory, hold your horses there, I know what you're going to say, that's not the case...) on /etc/xdg/xfce4/ and on /etc/skel/
Default live-session user login into desktop doesn't work.
2) Switch to TTY, sudo su, startx works
3) Root account startx gives me a "stock" (very old looking) Xfce desktop. Shouldn't it be the values that I manually specified in /etc/xdg/ ? During the Chroot process, I also replaced Thunar and taskmanager (I honestly can't remember if I replaced /xfce4/ files too, I think I left them alone for fear of breaking something) Even in the root account, Thunar settings I specified are not respected, despite Thunar files being replaced and copied into /root/.config/Thunar/
From where are the settings being read then? From where are they being loaded? User has no control anymore?
4) TTY, sudo su, adduser user, login, startx works (LightDM is stuck with default Live-Session user and can't be killed, process is hung up by systemd)
5) Newly created user works as intended, ALL settings are properly inherited from /etc/skel/ ...
6) How to achieve the same end result for the stock Live-Session user? This has been done in the past, doesn't work anymore.
7) Is there a 3rd place settings values are accessed from? /etc/xdg and /etc/skel/ seem to not be enough...
8) Live-Session 1st boot complains about "not finding files at /etc/xdg/" but it's clear the files are there. Is there some kind of checksum verification at 1st boot that prevents files from being replaced?
Settings specified by the user are not respected for a custom ISO. Until this is resolved somehow, the issue stands.
Offline
[ Generated in 0.012 seconds, 7 queries executed - Memory usage: 698.63 KiB (Peak: 747.47 KiB) ]