You are not logged in.
Pages: 1
Topic closed
In the past, on Xubuntu 16.04, I`ve used to migrate my xfce4 settings simply by replacing files inside of /home/user/.config/xfce4/, restarting panel and logging off...
With newer distros that use Xfce, this doesn`t seem to be possible anymore. (or was it something that only worked in Xubuntu?)
I`ve became tired of trying different methods and it not working, so I`m changing my approach to it now.
Instead of doing changes from the GUI, I want to do everything from terminal commands now (so I don`t have to repeat all the same steps manually everytime that I login or reboot)
I have to: (apparently in this order, correct me if I`m wrong)
1) Add multiple xfce4 plugins to the panel
2) Change each plugin`s individual settings (this is the step I`ve been unable to find any info on, I can only do it from GUI, it saves the XML files, but the problem is these XML files are not read when I reboot, the panel starts from a "fresh state"
3) Change keyboard layout from terminal command, this setting is also lost everytime I reboot
4) Keyboard shortcuts (these I have already figured out and I already have them inside of a script using xfconf commands)
5) Favorite items in whisker menu
6) Thunar settings (they are also lost in reboots) All of this worked before simply replacing /.config/xfce4/ and logging off
7) Power/Energy settings (never suspend or turn screen off, timers set to Zero or Never)
8) restart panel and logoff to apply changes
Is there a way to achieve all of this from command line?
Please tell me in advance if there`s not, so I don`t lose any more time with this crap.
Offline
About 7) Power/Energy settings, you can control those using xfconf-query
List all applications that can be configured:
xfconf-query -l
Preview the settings of xfce4-power-manager:
xfconf-query -c xfce4-power-manager -lv
Set a boolean value:
xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/show-tray-icon -t bool -s true
Set an integer value:
xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/show-panel-label -t int -s 1
Full xfconf-query docs:
https://docs.xfce.org/xfce/xfconf/xfconf-query
For 3) Change keyboard layout, you can also configure it through xfconf-query in the same manner:
xfconf-query -c keyboard-layout -lv
Same goes for 6) Thunar settings:
xfconf-query -c thunar -lv
For 5) Favourite items in whisker menu, I think whiskermenu doesn't have a CLI interface.
For favourites, you can set them up through
~/.config/xfce4/panel/whiskermenu-1.rc
and then the favourites key.
You can find the file names of your favourite apps in:
ls /usr/share/applications
Actually, wouldn't copying the whole whiskermenu-1.rc work?
I'm not sure about the rest, but I hope they can be configured somehow. Worst case scenario, you can write a script which simulates clicks on the desktop using xdotool. This sounds crazy and I'm not sure how viable it is
Edit: Just remembered about xfce4-panel-profiles:
https://docs.xfce.org/apps/xfce4-panel-profiles/start
This might work for your case with the plugins, but I'm not sure if it has a CLI interface.
Edit 2: After some more digging, the CLI interface for xfce4-panel-profiles works as follows (on Xubuntu 18.04):
1. Configure your panel through the GUI
2. To save the config, use:
xfpanel-switch save config_name.tar.bz2
3. To load the config, use:
xfpanel-switch load config_name.tar.bz2
Last edited by PaperNick (2020-12-05 16:42:22)
Offline
Thanks PaperNick!
I hope these steps will get normalized and eventually documented and scripted or included in Xfce in some way. Let's see if the end of the GTK3 transition brings it.
FeelingShred, please, tell us how it goes, I'm sure this thread will be visited a lot of times!
Offline
OK, just give some time to make some tests.
I'm trying to come up with different strategies to workaround that problem (yeah, the problem we will continue pretending doesn't exist... that one... the problem that Xfce devs and distribution maintainers have been ignoring... this is essential stuff for the usability of a system... and no, I'm not giving you an easy time with it... no, I'm not giving you an easy cop out for it... don't play dumb on me...)
I'm currently in the middle of attempting to build an ISO from Chroot method, but I had been facing specific issues to that along the way.
Every time I fix one thing, two other issues appear in the way. For each one of them, time is required. And divide it with other tasks. Linux was supposed to save me time, not make me have less of it.
And just to remember that every single one of these issues stemming from the fact that Xfce is still not saving settings across reboots.
Initially, I thought systemd was culprit for it, or at least one of the reasons for developers having to work around it, in convoluted ways... But I just became aware of the fact that MX Linux doesn't make use of systemd? So this is a Xfce issue then. (again: probably caused, in the first place, by updates providing workarounds to deal with systemd, but these updates are affecting ALL versions of Xfce, regardless of what distro one chooses)
I've been posting about this issue on forums for pretty much 2 weeks now.
NOT A SINGLE WORD to explain me or provide info on what XFCONF is doing or how it is working.
Where is Xfconf storing all these values? (panel settings, etc)
It is storing them somewhere. But when I rename ~/.config/xfce4/ directory and make a new login, I see that the directory gets re-populated WITHOUT Xfconf directory in it. It is reading the values from some other place that is not stored on disk. This is not the way it was intended to work. Seems to me such a rather simple bug to fix, or to at least track down.
Offline
Thunar settings is a different thing entirely (but part of the same problem)
Task manager settings too.
When I try to manually copy files from ~/.config/xfce4 to /etc/skel/.config/xfce4 or to /etc/xdg/ I create a new user and I log in. The new user is not inheriting the Thunar and TaskManager settings that I specifically chose.
This is downright BROKEN.
And I'm not sugarcoating it for any of you. (the devs I mean)
Last edited by FeelingShred (2020-12-06 06:45:20)
Offline
There might be another alternative, a Plan C to this stupid innane bullshit: rolling back to a previous version of xfce4 entirely (the one that worked, on 16.04, was 4.12)
How could I rollback xfce4 entirely? Will it potentially break my system? I would need to rollback xfconf and a few others too, I have the list of versions.
Or would it be easier to build it from the ground up package-by-package using a small Minimal or NetInstall type of ISO?
Anyone ever went through a procedure like this?
Offline
NOT A SINGLE WORD to explain me or provide info on what XFCONF is doing or how it is working.
Where is Xfconf storing all these values? (panel settings, etc).
Xfconf stores its values in:
~/.config/xfce4/xfconf/xfce-perchannel-xml/
Here's a more in-depth guide for xfconf-query:
https://forum.xfce.org/viewtopic.php?pid=43171#p43171
This is downright BROKEN.
And I'm not sugarcoating it for any of you. (the devs I mean)
As to why it doesn't apply the settings when you replace the folder, did it ever occur to you that it might be distro-specific issue?
I'm copy-pasting my
~/.config/xfce4
folder every time after fresh install and it works seamlessly on Xubuntu.
My advise would be to not prematurely draw conclusions. Plus, your attitude towards the xfce devs is not acceptable in my opinion. You should pay more respect to the people who keep on working on xfce tirelessly. They dedicate their free time to work on this open source project which you use without paying a dime. We should nourish a more humble and thankful attitude.
When in doubt, you can always preview the source code when the documentation is lacking. Since you're building a distro, this should not be a problem for you:
https://gitlab.xfce.org/xfce/
Last edited by PaperNick (2020-12-06 09:55:58)
Offline
This is downright BROKEN.
And I'm not sugarcoating it for any of you. (the devs I mean)
The devs don't generally visit these forums. If you feel you have found a bug, please create a bug report at https://gitlab.xfce.org/xfce/xfconf/-/issues. The devs can be reached more directly via the xfce4-dev mailing list or via the #xfce-dev IRC channel.
That being said I just tested on Arch Linux. I copied ~/.config/xfce4 and ~/.config/Thunar to /etc/skel. Created a new user and logged in as tat new user. Both the settings of Thunar and the task manager were successfully copied over. Perhaps its something in the process you are using that is causing the conflict (or as PaperNick says, a distro issue)?
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
In the past, on Xubuntu 16.04, I`ve used to migrate my xfce4 settings simply by replacing files inside of /home/user/.config/xfce4/, restarting panel and logging off...
With newer distros that use Xfce, this doesn`t seem to be possible anymore. (or was it something that only worked in Xubuntu?)
I used to have similar troubles too. It turned out (after some digging on the internet I found advice from ToZ https://forum.xfce.org/viewtopic.php?id=11509) that the problem is in the fact that xfconfd process stores settings in memory and the process is not even killed when a user is logging out.
So working way how to transfer settings for a user:
The user must not have running XFCE (so settings can be transferred by an another user or by the same user in the text console accessible for example by CTRL-ALT-F4).
The user (for example "user_name") must not have running xfconfd process. This can be verified by
ps aux | grep user_name | grep xfconfd
and if the process was found, it must be killed.
After that settings stored in "/home/user_name/.config" can be overwritten/edited. Proper file owner must be set if settings were copied from another account.
I have just tested this approach on Xubuntu 20.04:
I created new user (user2) on my computer and logged in (so necessary files were copied into the new profile). I logged out.
As another user I copied config files into "/home/user2/.config" directory and changed the owner to user2:user2
sudo chmod -R user2:user2 /home/user2/.config/*
Logged as the user2 and realized that new settings do not affect the profile. Logged out.
As another user I killed the xfconfd process which belonged to user2.
Logged in as user2 again and new settings were working.
ToZ in https://forum.xfce.org/viewtopic.php?id=11509 mentioned that killing user processes during logout can be set in file /etc/systemd/logind.conf by setting:
KillUserProcesses=yes
I have not tested this yet.
Last edited by Signy (2020-12-06 14:50:04)
Offline
Xfconf stores its values in:
~/.config/xfce4/xfconf/xfce-perchannel-xml/
Here's a more in-depth guide for xfconf-query:
https://forum.xfce.org/viewtopic.php?pid=43171#p43171
The guy just goes on to not read what I detailed in-depth before. Typical. That's exactly the issue that I'm addressing. Just knowing how to post a bunch of technical and fancy terminal commands in quotes don't mean that you are the all-around authority on terms of knowledge. Starts with reading what's been posted.
If something was posted, and written down, is that because there's a reason for it, in the first place. XML files, says Mr Obvious. Of course there are XML files, that's what I've been saying all along.
I used to have similar troubles too. It turned out (after some digging on the internet I found advice from ToZ https://forum.xfce.org/viewtopic.php?id=11509) that the problem is in the fact that xfconfd process stores settings in memory and the process is not even killed when a user is logging out.
So working way how to transfer settings for a user:
The user must not have running XFCE (so settings can be transferred by an another user or by the same user in the text console accessible for example by CTRL-ALT-F4).
The user (for example "user_name") must not have running xfconfd process. This can be verified by
ps aux | grep user_name | grep xfconfd
and if the process was found, it must be killed.
OK! YES! NOW we have something of actual substance. Thank you, person who reads and is able to comprehend. Finally!
Now we are on to something. And something that is actually technical, not just parrot wiki articles.
OK, that's the thing I've been trying to say. Let me go in steps, because this gets too complicated too fast.
From my tests across 5 different reboots into Live-Sessions and 2 different distros (Manjaro, MX-Debian) across 3 weeks, I've been finding that there's something odd with Xfconf. I don't remember at what exact point this happened (information has been piling up at this point, excuse me for not being a robot that never forgets anything, I just want to use the computer that I paid for) I don't remember at what point I logged off into a TTY terminal to kill xfconf and it was NOT running. Sometimes it was running after logout, but I don't recall which specific times.
So now it's the breakdown and the questions we need to answer before we can move forward:
I have also noticed this: even though I was able to sudo killall xfconf without error messages (signifying that the process was killed indeed, or that it was running) I never recall a single instance where Xfconf appeared in top or task manager. Xfsettings appear in task manager, but Xfconf doesn't. Is that behavior intended? Or i it a sympton that something is not right? Is it supposed to be running during the entire session or just at login time? None of these things are documented out there, and it's not exactly clear.
edit: 2nd part of the question I just reminded about:
I also remember noticing that after I would kill Xfconf the 1st time, it would not be running when I wanted to kill it on the next logout.
Is Xfconf a command that needs to be activated at login time? Can we start it manually? How does that aspect of it work? There's not a terminal alias for it, there's no executables called Xfconf or Xfconfd
edit number 3: stuff gets to complicated that I forget some things while I'm typing others.
This is another crucial element of all of this: I'm not installing on disk. I am creating ISO remasters/respins out of a Live Session.
Which translates into: Reboots are not really possible for me. Things like you recommended that require a reboot to be applied, that won't work with me.
What I CAN try is: applying that setting into the chroot machine itself, that I can try. But even then, "re-enabling KillUserProcessesAtLogout" won't break other things as collateral effect? So I'm fixing one thing, but breaking others. Like I said before: stuff gets complex, really fast.
ToZ in https://forum.xfce.org/viewtopic.php?id=11509 mentioned that killing user processes during logout can be set in file /etc/systemd/logind.conf by setting:
KillUserProcesses=yes
I have not tested this yet.
Again, this is awesome, THANKS again. You are absolutely right on the spot there, that's it.
I've stumbled upon this before (long before I decided to create forum accounts and post in different forums, because that was a last resort kind of measure really, I didn't expect things to arrive at this rock bottom situation)
Here's the thing: like I detailed above, I noticed that Xfconf was not running at all times, only Xfsettings was running. I'm not typing the questions again, read above please This is a valid answer yes and you're right, but I have noticed the system appears to not be running the way it's intended.
Let's move in steps and eventually I think we will stumble unto the exact point at which stuff is breaking. Thanks again.
If this was the level of replies all around, instead of denying what I've said like I don't know what I'm talking about, I would not need to post replies in such an angry and cynical manner.
Isn't it nice when people treat you with respect? So you can treat them with respect back. It takes 2 to dance.
Isn't it so nice and awesome? I think it is.
Last edited by FeelingShred (2020-12-06 21:10:58)
Offline
Update: (while I wait for the answers to the questions before)
(this reply here is optional, it's just to give you an idea of what I'm going through... I'm not just sitting here and waiting...)
Being that I can't run GUI apps like xfce4-panel or xfce4-settings-manager inside of the chroot (for whatever reason) and being that I CAN run Thunar inside of Chroot but it won't save the settings that I define for it (all of these things that I did in the past, and it worked) I decide "OK, let's try the virtual machine method."
I am here on Oracle VM's installing instructions page, I download this "apt secure public key" thing, only to greeted by terminal saying this to me:
"apt-key is deprecated"
I go into google, only to be surprised with people asking about the same thing, and no solution currently existing as of December 2020
This thing is turning into a NIGHTMARE
Is this what Linux became in the past 4 years, while I was comfortly protected by my un-updated ISO?
What are these people doing? My god...
Oracle's official site is offering instructions that don't even work anymore.
And, of course, they don't have comments on their page.
https://www.virtualbox.org/wiki/Linux_Downloads
What the hell even is this?
Deprecated why? Who even uses apt keys to begin with?
edit: So basically, what I suspect I'm gonna have to do is: unable to install this thing using Apt-Key on Xubuntu, I will have to close all my stuff, reboot once again into Manjaro, because at least on Manjaro I know that I install apps in a much simpler way, and possibly (Hopefully, if the gods in the Olympus allow me) install a Xubuntu Virtual Machine from there, from the Xubuntu ISO. ALL OF THIS in order for me to be able to change my desktop and visual settings, panel settings.
I am not insane, I swear to you.
What are these guys doing??? This is unprecedent levels of madness. Not even Windows 10 reached this far with group policies, regedit and the like.
edit number 2:
More technical bullshit info if it helps with anything towards we tracking down what the problem is with Xfce accessing values from memory rather than disk
There right here were the warnings I was getting in the terminal while using Chroot to build a custom ISO... xfce4-panel and mousepad (text editor) could not be initialized... Thunar could be initialized, but settings would not be preserved, even opening new windows with right-click...
: dbind-WARNING **: 19:00:38.097:
Couldn't register with accessibility bus: Did not receive a reply.
Possible causes include: the remote application did not send a reply,
the message bus security policy blocked the reply, the reply timeout expired,
or the network connection was broken.
Qt WARNING: QXcbConnection: XCB error: 3 (BadWindow),
sequence: 53350, resource id: 8832600,
major code: 40 (TranslateCoords), minor code: 0
And this is something weird that I noticed while browsing /etc/xdg/xfce4/panel/ there was this file Default.xml that I haven't seen before.
Creating new users will not make this file spawn in the User's /.config/xfce4/ directory
Also, modify date, this file haven't been modified since I've booted my system 3 days ago, it's the same modified date as the Xubuntu ISO release date, or the date it was last accessed rather.
$ sudo fuser -m /etc/xdg/xfce4/panel/default.xml
Cannot stat file /proc/512356/fd/10: Permission denied
[ ...dozens of more lines redacted...]
Cannot stat file /proc/516837/fd/10: Permission denied
/etc/xdg/xfce4/panel/default.xml: 1rce 2rc 3rc 4rc 6rc 9rc 10rc 11rc 12rc 13rc 14rc 15rc 16rc 17rc 18rc 20rc 21rc 22rc 23rc 24rc 26rc 27rc 28rc 29rc 30rc 32rc 33rc 34rc 35rc 36rc 38rc 39rc 40rc 41rc 42rc 44rc 45rc 46rc 47rc 48rc 50rc 51rc 52rc 53rc 54rc 56rc 58rc 59rc 60rc 61rc 62rc 64rc 65rc 66rc 67rc 68rc 69rc 116rc 117rc 118rc 119rc 120rc 121rc 122rc 123rc 125rc 128rc 129rc 131rc 132rc 134rc 135rc 139rc 141rc 143rc 153rc 156rc 157rc 162rc 203rc 204rc 226rc 242rc 247rc 248rc 249rc 250rc 251rc 252rc 253rc 254rc 255rc 256rc 257rc 258rc 259rc 260rc 261rc 262rc 263rc 264rc 265rc 267rc 272rc 275rc 276rc 282rc 283rc 339rc 347rc 348rc 350rc 351rc 352rc 353rc 354rc 355rc 356rc 357rc 358rc 359rc 452rc 484rc 510rc 1135rce 1154rce 1223rc 1224rc 1225rc 1240rc 1296rc 1298rc 1300rc 1301rc 1302rc 1443rc 1444rc 1445rc 1446rc 1448rc 1449rc 1450rc 1451rc 1452rc 1453rc 1454rc 1455rc 1473rce 1474rce 1478rce 1479rce 1483rce 1485rce 1486rce 1490rce 1491rce 1498rce 1502rce 1503rce 1505rce 1507rce 1510rce 1511rce 1515rce 1540rce 1547rce 1611rce 1616rce 1736rce 1737rce 1755e 1758rce 1782rc 1980rce 1985rce 1989rce 2002rce 2007rce 2045rce 2128rce 2155rce 2188rce 2194rce 2248rce 2253rce 2257rce 2261rce 2265rce 2280rce 2285rce 2296rce 2298rce 2303rce 2433rce 2454rce 2473rce 2474rce 2487rce 2488rce 2489rce 2501rce 2557rce 3193rce 3205rce 3331rce 3332rce 3352rce 3467rce 3568rce 3584rce 3610rce 3639rce 3658rce 3718rce 3722rce 3723rce 3727rce 3731rce 3768rce 3795rce 3884rce 4136rc 4137rc 4394rce 4399rce 4451rce 4474rce 4505rce 4553rce 10312rce 10316rce 25814rce 26946rce 26947rce 26950rce 26958rce 26963rce 26965rce 128801re 128857rce 263503rce 284567rce 284569rce 301664re 301665re 301666re 301667re 301668re 301669re 301670re 301671re 301672re 301673re 301674re 301675re 301676re 301680re 328775rce 330086rce 458826rc 468215rce 470717rc 478485rc 478486rc 478976re 484189rc 484329rce 500103rc 503255rc 503345rc 505898rc 507725rc 508877rc 508878rc 510638rc 510639rc 512025re 512356rce 512359rc 512364rc 512370rc 512394rc 512400rc 512458 512483 512499 512558rc 512575rc 512585rc 512763rc 514462rc 514980 516172 516190rc 516837 517124rc
517125rc 517498rc 518640rc 518641rc 518642rc 518643rc 519058rce 519074rce
$ sudo fuser -m /etc/xdg/xdg-xubuntu/xfce4/panel/default.xml
Cannot stat file /proc/512356/fd/10: Permission denied
[...dozens of more lines redacted...]
Cannot stat file /proc/516837/fd/10: Permission denied
/etc/xdg/xdg-xubuntu/xfce4/panel/default.xml: 1rce 2rc 3rc 4rc 6rc 9rc 10rc 11rc 12rc 13rc 14rc 15rc 16rc 17rc 18rc 20rc 21rc 22rc 23rc 24rc 26rc 27rc 28rc 29rc 30rc 32rc 33rc 34rc 35rc 36rc 38rc 39rc 40rc 41rc 42rc 44rc 45rc 46rc 47rc 48rc 50rc 51rc 52rc 53rc 54rc 56rc 58rc 59rc 60rc 61rc 62rc 64rc 65rc 66rc 67rc 68rc 69rc 116rc 117rc 118rc 119rc 120rc 121rc 122rc 123rc 125rc 128rc 129rc 131rc 132rc 134rc 135rc 139rc 141rc 143rc 153rc 156rc 157rc 162rc 203rc 204rc 226rc 242rc 247rc 248rc 249rc 250rc 251rc 252rc 253rc 254rc 255rc 256rc 257rc 258rc 259rc 260rc 261rc 262rc 263rc 264rc 265rc 267rc 272rc 275rc 276rc 282rc 283rc 339rc 347rc 348rc 350rc 351rc 352rc 353rc 354rc 355rc 356rc 357rc 358rc 359rc 452rc 484rc 510rc 1135rce 1154rce 1223rc 1224rc 1225rc 1240rc 1296rc 1298rc 1300rc 1301rc 1302rc 1443rc 1444rc 1445rc 1446rc 1448rc 1449rc 1450rc 1451rc 1452rc 1453rc 1454rc 1455rc 1473rce 1474rce 1478rce 1479rce 1483rce 1485rce 1486rce 1490rce 1491rce 1498rce 1502rce 1503rce 1505rce 1507rce 1510rce 1511rce 1515rce 1540rce 1547rce 1611rce 1616rce 1736rce 1737rce 1755e 1758rce 1782rc 1980rce 1985rce 1989rce 2002rce 2007rce 2045rce 2128rce 2155rce 2188rce 2194rce 2248rce 2253rce 2257rce 2261rce 2265rce 2280rce 2285rce 2296rce 2298rce 2303rce 2433rce 2454rce 2473rce 2474rce 2487rce 2488rce 2489rce 2501rce 2557rce 3193rce 3205rce 3331rce 3332rce 3352rce 3467rce 3568rce 3584rce 3610rce 3639rce 3658rce 3718rce 3722rce 3723rce 3727rce 3731rce 3768rce 3795rce 3884rce 4136rc 4137rc 4394rce 4399rce 4451rce 4474rce 4505rce 4553rce 10312rce 10316rce 25814rce 26946rce 26947rce 26950rce 26958rce 26963rce 26965rce 128801re 128857rce 263503rce 284567rce 284569rce 301664re 301665re 301666re 301667re 301668re 301669re 301670re 301671re 301672re 301673re 301674re 301675re 301676re 301680re 328775rce 330086rce 458826rc 468215rce 470717rc 478485rc 478486rc 478976re 484189rc 484329rce 500103rc 503255rc 503345rc 505898rc 507725rc 508877rc 508878rc 510638rc 510639rc 512025re 512356rce 512359rc 512364rc 512370rc 512394rc 512400rc 512458 512483 512499 512558rc 512575rc 512585rc 512763rc 514462rc 514980 516172 516190rc 516837 517124rc
517125rc 517498rc 518640rc 518641rc 518642rc 518643rc 519058rce 519121rce
Notice how the same processes access the file Default.xml that exists in two different locations. Except by the last few processes there that differ.
Both versions of the file are being accessed at the same time, somehow. Is it supposed to be like that?
And these right here are the processes output of the same exact command WHILE I was using Chroot the edit my ISO, while the warnings were appearing in terminal:
$ sudo find /home /bin /lib /lib64 /rofs /usr /etc /var /opt /sbin /snap /srv -type f -name "default.xml"
/rofs/etc/xdg/xdg-xubuntu/xfce4/panel/default.xml
/rofs/etc/xdg/xfce4/panel/default.xml
/etc/xdg/xdg-xubuntu/xfce4/panel/default.xml
/etc/xdg/xfce4/panel/default.xml
$ sudo fuser -m /etc/xdg/xfce4/panel/default.xml
/etc/xdg/xfce4/panel/default.xml: 1rce 2rc 3rc 4rc 6rc 9rc 10rc 11rc 12rc 13rc 14rc 15rc 16rc 17rc 18rc 20rc 21rc 22rc 23rc 24rc 26rc 27rc 28rc 29rc 30rc 32rc 33rc 34rc 35rc 36rc 38rc 39rc 40rc 41rc 42rc 44rc 45rc 46rc 47rc 48rc 50rc 51rc 52rc 53rc 54rc 56rc 58rc 59rc 60rc 61rc 62rc 64rc 65rc 66rc 67rc 68rc 69rc 116rc 117rc 118rc 119rc 120rc 121rc 122rc 123rc 125rc 128rc 129rc 131rc 132rc 134rc 135rc 139rc 141rc 143rc 153rc 156rc 157rc 162rc 203rc 204rc 226rc 242rc 247rc 248rc 249rc 250rc 251rc 252rc 253rc 254rc 255rc 256rc 257rc 258rc 259rc 260rc 261rc 262rc 263rc 264rc 265rc 267rc 272rc 275rc 276rc 282rc 283rc 339rc 347rc 348rc 350rc 351rc 352rc 353rc 354rc 355rc 356rc 357rc 358rc 359rc 452rc 484rc 510rc 1135rce 1154rce 1223rc 1224rc 1225rc 1240rc 1296rc 1298rc 1300rc 1301rc 1302rc 1443rc 1444rc 1445rc 1446rc 1448rc 1449rc 1450rc 1451rc 1452rc 1453rc 1454rc 1455rc 1473rce 1474rce 1478rce 1479rce 1483rce 1485rce 1486rce 1490rce 1491rce 1498rce 1502rce 1503rce 1505rce 1507rce 1510rce 1511rce 1515rce 1540rce 1547rce 1611rce 1616rce 1736rce 1737rce 1755e 1758rce 1782rc 1980rce 1985rce 1989rce 2002rce 2007rce 2045rce 2128rce 2155rce 2188rce 2194rce 2248rce 2253rce 2257rce 2261rce 2265rce 2280rce 2285rce 2296rce 2298rce 2303rce 2433rce 2454rce 2473rce 2474rce 2487rce 2488rce 2489rce 2501rce 2557rce 3193rce 3205rce 3331rce 3332rce 3352rce 3467rce 3568rce 3584rce 3610rce 3639rce 3658rce 3718rce 3722rce 3723rce 3727rce 3731rce 3768rce 3795rce 3884rce 4136rc 4137rc 4394rce 4399rce 4451rce 4474rce 4505rce 4553rce 10312rce 10316rce 19646rce 25814rce 26946rce 26947rce 26950rce 26958rce 26963rce 26965rce 68474rce 68475re 68702rc 69282re 69296re 128801re 128857rce 263503rce 284567rce 284569rce 301664re 301665re 301666re 301667re 301668re 301669re 301670re 301671re 301672re 301673re 301674re 301675re 301676re 301680re 328775rce 330086rce 458826rc 466908rc 468215rce 470717rc 473116rce 478485rc 478486rc 478976re 478988re 479023re 479029re 479400rc 479703rc 479704rc 484189rc 484206rc 484329rce 484752rc 484768rc 500103rc 501226rc 501247rc 503035rc
503255rc 503256rc 503345rc 503346rc 504481rc 505169rce 505671rce
$ sudo fuser -m /etc/xdg/xdg-xubuntu/xfce4/panel/default.xml
/etc/xdg/xdg-xubuntu/xfce4/panel/default.xml: 1rce 2rc 3rc 4rc 6rc 9rc 10rc 11rc 12rc 13rc 14rc 15rc 16rc 17rc 18rc 20rc 21rc 22rc 23rc 24rc 26rc 27rc 28rc 29rc 30rc 32rc 33rc 34rc 35rc 36rc 38rc 39rc 40rc 41rc 42rc 44rc 45rc 46rc 47rc 48rc 50rc 51rc 52rc 53rc 54rc 56rc 58rc 59rc 60rc 61rc 62rc 64rc 65rc 66rc 67rc 68rc 69rc 116rc 117rc 118rc 119rc 120rc 121rc 122rc 123rc 125rc 128rc 129rc 131rc 132rc 134rc 135rc 139rc 141rc 143rc 153rc 156rc 157rc 162rc 203rc 204rc 226rc 242rc 247rc 248rc 249rc 250rc 251rc 252rc 253rc 254rc 255rc 256rc 257rc 258rc 259rc 260rc 261rc 262rc 263rc 264rc 265rc 267rc 272rc 275rc 276rc 282rc 283rc 339rc 347rc 348rc 350rc 351rc 352rc 353rc 354rc 355rc 356rc 357rc 358rc 359rc 452rc 484rc 510rc 1135rce 1154rce 1223rc 1224rc 1225rc 1240rc 1296rc 1298rc 1300rc 1301rc 1302rc 1443rc 1444rc 1445rc 1446rc 1448rc 1449rc 1450rc 1451rc 1452rc 1453rc 1454rc 1455rc 1473rce 1474rce 1478rce 1479rce 1483rce 1485rce 1486rce 1490rce 1491rce 1498rce 1502rce 1503rce 1505rce 1507rce 1510rce 1511rce 1515rce 1540rce 1547rce 1611rce 1616rce 1736rce 1737rce 1755e 1758rce 1782rc 1980rce 1985rce 1989rce 2002rce 2007rce 2045rce 2128rce 2155rce 2188rce 2194rce 2248rce 2253rce 2257rce 2261rce 2265rce 2280rce 2285rce 2296rce 2298rce 2303rce 2433rce 2454rce 2473rce 2474rce 2487rce 2488rce 2489rce 2501rce 2557rce 3193rce 3205rce 3331rce 3332rce 3352rce 3467rce 3568rce 3584rce 3610rce 3639rce 3658rce 3718rce 3722rce 3723rce 3727rce 3731rce 3768rce 3795rce 3884rce 4136rc 4137rc 4394rce 4399rce 4451rce 4474rce 4505rce 4553rce 10312rce 10316rce 19646rce 25814rce 26946rce 26947rce 26950rce 26958rce 26963rce 26965rce 68474rce 68475re 68702rc 69282re 69296re 128801re 128857rce 263503rce 284567rce 284569rce 301664re 301665re 301666re 301667re 301668re 301669re 301670re 301671re 301672re 301673re 301674re 301675re 301676re 301680re 328775rce 330086rce 458826rc 466908rc 468215rce 470717rc 473116rce 478485rc 478486rc 478976re 478988re 479023re 479029re 479400rc 479703rc 479704rc 484189rc 484206rc 484329rce 484752rc 484768rc 500103rc 501226rc 501247rc 503035rc
503255rc 503256rc 503345rc 503346rc 504481rc 505169rce 505673rc 505754rce
The processes that differ there, according to my taskmanager, are:
1443 [spl_system_task]
1782rc [krfcommd]
1980rce /usr/lib/exec/at-spi-bus-launcher
1985rce /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2
1989rce xfconfd
2002rce gvfsd
3352 xfce4-session
3610 xfsettingsd --display:1.0 --sm-client-id
519058 bash
518643 [kworker/4:1-events]
Is this relevant to anything? Basically my entire system is accessing both these two files at the same time, all the time?
And is it normal to have copies of these files in /rofs/etc/xdg/ ??
Last edited by FeelingShred (2020-12-07 01:27:08)
Offline
(there are two threads now, this is a copy of the update given on the "xfconfd settings" thread...)
Succesfully booted custom ISO created with Chroot.
1) During ISO creation, 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/
On 1st boot, default stock 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?
9) Can't remove the stock "Xubuntu" user because process is hung up by systemd, can't kill it (something that I remember doing in 16.04 without any problems)
Settings specified by the user are not respected for a custom snapshot ISO. Until this is resolved somehow, the issue stands.
The Xfce desktop is being structured in a way that systemd has complete control over it and will override any custom settings the user chooses to have.
Offline
I have also noticed this: even though I was able to sudo killall xfconf without error messages (signifying that the process was killed indeed, or that it was running) I never recall a single instance where Xfconf appeared in top or task manager. Xfsettings appear in task manager, but Xfconf doesn't. Is that behavior intended? Or i it a sympton that something is not right? Is it supposed to be running during the entire session or just at login time? None of these things are documented out there, and it's not exactly clear.
On Xubuntu 20.04 I can see xfconfd in Task manager. And in
ps aux | grep xfconfd
I can see twoo of them, one for me and one for root.
edit: 2nd part of the question I just reminded about:
I also remember noticing that after I would kill Xfconf the 1st time, it would not be running when I wanted to kill it on the next logout.
Is Xfconf a command that needs to be activated at login time? Can we start it manually? How does that aspect of it work? There's not a terminal alias for it, there's no executables called Xfconf or Xfconfd
I am no expert, so just my experience with Xubuntu 20.04.
As I use the setting
KillUserProcesses=yes
I do not have to kill xfconfd manually.
And when I log into XFCE session, the process is started automatically (even if it is the second login so the process must have been killed by the previous logout).
edit number 3: stuff gets to complicated that I forget some things while I'm typing others.
This is another crucial element of all of this: I'm not installing on disk. I am creating ISO remasters/respins out of a Live Session.
Which translates into: Reboots are not really possible for me. Things like you recommended that require a reboot to be applied, that won't work with me.
What I CAN try is: applying that setting into the chroot machine itself, that I can try. But even then, "re-enabling KillUserProcessesAtLogout" won't break other things as collateral effect? So I'm fixing one thing, but breaking others. Like I said before: stuff gets complex, really fast.
The change in /etc/systemd/logind.conf mentioned earlier works for me. I tested it as a user was logged in TTY console and the same was user logged in another session in XFCE. After logging-out from the XFCE session, the previous TTY console stayed intact - so it looks OK. Of course it does not mean that any troubles can emerge in other situations.
Here's the thing: like I detailed above, I noticed that Xfconf was not running at all times, only Xfsettings was running. I'm not typing the questions again, read above please This is a valid answer yes and you're right, but I have noticed the system appears to not be running the way it's intended.
I have not a clue why xfconfd is not running on your system all the time when a user is running XFCE. On my system xfconfd is running all the time when XFCE runs (even on a life Xubuntu 20.04).
BTW: I have no experience with chroot and graphical applications so, nor with playing with default settings for new users - so I can tell you anything about these topics.
Last edited by Signy (2020-12-09 14:50:56)
Offline
On Xubuntu 20.04 I can see xfconfd in Task manager. And in
ps aux | grep xfconfd
I can see twoo of them, one for me and one for root.
The change in /etc/systemd/logind.conf mentioned earlier works for me. I tested it as a user was logged in TTY console and the same was user logged in another session in XFCE. After logging-out from the XFCE session, the previous TTY console stayed intact - so it looks OK. Of course it does not mean that any troubles can emerge in other situations.
BTW: I have no experience with chroot and graphical applications so, nor with playing with default settings for new users - so I can tell you anything about these topics.
update: I got the new custom ISO made with Chroot running, it works properly only when I create a new user.
https://imgur.com/a/CxFSrxb
Just as a test, I manually copied/replaced just the Thunar settings file for the root account, when creating the ISO. Replace it both on /root/.config/ and on /etc/xdg/ (for a test) Root account still doesn't inherit the custom Thunar settings. User has no control, settings are overriden from somewhere else, but no one from the Xfce team shares where it comes from.
Ok, I see xfconfd running. Only for the user though, not root. So forget that, that might be bullocks from my part earlier.
edit: I forgot... Will try that /etc/systemd/logind.conf thing you mentioned.
I am considering the thread closed for now, until someone finds something relevant in the future and reply to the thread, so it can be shared with others too.
Thanks for your time, I don't recommend that you waste any more time into this. Thanks to the german guy on the other thread for sharing useful info about /etc/xdg/ and stuff (the xfce team did not come to answer him too... I'm talking about people who deal with the code directly, they know exactly the info we're looking for, don't come play dumb on me...)
Issues that remain unaddressed by the Xfce team as of now: (and comes to only people who maintain the code to answer this, there's no way others would know about this, particularly in regards to what's going on with DBUS and such)
1) Thunar settings. If this is an issue only of Xfce, why are Thunar settings affected too? Replacing Thunar settings files manually (in more than one location, while the system is not booted even) doesn't result in changes. Settings are being overriden from somewhere else.
2) No one provided info on how Xfconfd works exactly. Should we kill xfconfd in order to replace XML config files manually? Should we do all the procedure from Root account, from tty? Should we leave Xfconfd running? What does this process do exactly? Why is it running in the background? Is Xfconfd even related to any of this?
These things can only be told by the Xfce maintainers itself, regular forum users don't waste your time looking in the source code unless you have time to burn.
These guys know what's going on. Let this be documented here in case they decide to stay silent. (not big news, threads from 2012 having the same issue, no one cares, we are on our own)
Last edited by FeelingShred (2020-12-09 17:27:52)
Offline
Maybe you didn't absorb this fully:
The devs don't generally visit these forums. If you feel you have found a bug, please create a bug report at https://gitlab.xfce.org/xfce/xfconf/-/issues. The devs can be reached more directly via the xfce4-dev mailing list or via the #xfce-dev IRC channel.
That being said I just tested on Arch Linux. I copied ~/.config/xfce4 and ~/.config/Thunar to /etc/skel. Created a new user and logged in as tat new user. Both the settings of Thunar and the task manager were successfully copied over. Perhaps its something in the process you are using that is causing the conflict (or as PaperNick says, a distro issue)?
I suspect (but could be wrong) most of your problems have to do with the fact you're trying to alter the ISO, not the installed OS. You may need to take your questions to the creators of the ISO or install the system, make your changes, then create an ISO out of the installed OS.
Offline
"alter the ISO" is not black magic, it's a relatively simple procedure...
If you don't know how to do it, leave it for people that know it.
And stop randomly replying to threads you have no knowledge about LOL That would be a good start I guess.
edit: Let it be also documented that the guys on the MX Forums closed the thread not leaving chance for further info being shared in the thread in the future.
I can't see how exactly that would benefit anyone, or how that could contribute to the issue being fixed.
They close threads in spite for someone not wanting to bow down to their little "forum authority".
It's not really related to sharing knowledge and leaving open for others to share new discories too, you see?
Very interesting what little amount of apparent "power" will do to people's heads, isn't it?
Last edited by FeelingShred (2020-12-09 18:19:16)
Offline
You didn't get the point.
This forum is users trying to help other users. ToZ gave you links for the best places to get help with your issues.
Offline
You didn't get the point.
Actually reading what is written and detailed in the thread goes a long way.
This is not something exclusive to Live-Sessions.
Installed systems have the same issues. As of now, Xfce 4.14 is bugged.
https://forums.linuxmint.com/viewtopic.php?t=318350
https://forums.linuxmint.com/viewtopic.php?t=279620
https://forum.xfce.org/viewtopic.php?id=12099
https://forum.xfce.org/viewtopic.php?id=7597
https://askubuntu.com/questions/883123/ … on-startup
https://askubuntu.com/questions/125350/ … ter-reboot
https://askubuntu.com/questions/1060116 … -reverting
A bunch of issues from a long time ago. Users are required to flesh out manual cumbersome hacks to do petty stuff that the desktop should be doing automatically, if it was functioning properly. A bunch of threads without permanent solutions being marked as "Solved" too. Others outright no response at all.
I mean, if a bunch of people want to come here in this thread and keep spilling false information, I will get back at ya every time. Every single time.
We can go on and on forever and ever with this.
As a rule of thumb, do not comment on specific issues you're not a specialist in. Never created an ISO yourself? Why even bother talking about ISO's then? Bunch of nonsense.
Never had custom Startup/Login scripts for automated deployment of multiple machines? So do not comment on it either.
Funny how that isn't a violation of "forums etiquette" huh? Goes to show how the rules are always single-sided.
Last edited by FeelingShred (2020-12-11 05:06:36)
Offline
This has gone far enough. The reason that your threads keep getting locked in different forums is not because of the content, but because of your attitude towards people who are trying to help. Therefore, this one is locked too.
If you have found a bug, file a bug report.
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
Pages: 1
Topic closed
[ Generated in 0.020 seconds, 7 queries executed - Memory usage: 768.98 KiB (Peak: 833.83 KiB) ]