Some really strange desktop session behaviour (xfce,but not only)

scar · 2015-09-29 18:37:25

Well, if I want to describe the problem, first I have to tell that yesterday I've deleted all my xfce config files (that means rm -rf ~/.config/xfce4*). X was not active, I did it from a tty.
In some very interesting way, when I tried to start X, I retrieved all my settings unmodified.
So I messed around for half an hour, tried some things, but every time I deleted xfce's settings, they remained unchanged.

Then I've built a new box in a VM (VirtualBox). I've only installed base, base-devel, xorg-server- xorg-xinit, xf86-video-vesa, grub and the xfce group.
I've made a test user, created .xinitrc to launch xfce, and started X. Blank desktop. I've made some modifications, exited the session, and did (while in the users home dir) an rm -rf .*
Logout, login as test user again, new .xinitrc (with exec startxfce4 as usual), and then I started X.
In a very strange way, I did not have the blank desktop, but the customized one, of which I previously deleted all the settings.

just for info, I've tried it with gnome too, it results in the same strange and - to me at least - unorthodox "bug"

So, what is happening here? How can it be possible, that all the settings remain unchanged even after deleting litetally everything in one's homedir?

Last edited by scar (2015-09-29 18:50:22)

berbae · 2015-09-30 08:14:35

rm -rf ~/.config/xfce4* <------not correct
rm -rf ~/.config/xfce4/* <------correct

rm -rf .* <-----not correct
rm -rf ./* <-----correct

For this last command, take care to be in the right directory.

respiranto · 2015-09-30 13:30:13

berbae wrote:

rm -rf .* <-----not correct
rm -rf ./* <-----correct

testuser ~/testdir $ rm -rf .*
rm: refusing to remove ‘.’ or ‘..’ directory: skipping ‘.’
rm: refusing to remove ‘.’ or ‘..’ directory: skipping ‘..’

However, this would be better:

rm -rf .[!.]*

By the way, I have just tested and experience the same behaviour.
XFCE seems to store its local settings globally, however user-writable.
Or does startx connect to some service with super user privileges?

Last edited by respiranto (2015-09-30 17:14:07)

berbae · 2015-09-30 14:53:40

@respiranto I do not agree with your

rm -rf .[!.]*

$ cd ~/.config
$ ls .[!.]*
ls: cannot access .[!.]*: No such file or directory
$ ls .*
.:
list of repertories and files under ~/.config
..:
list of repertories and files under $HOME
$ ls ./*
list of files under ~/.config
then list of repertories under ~/.config and their content (depth 1 only)
$ ls *
same as 'ls ./*'

So for me the right command is:
rm -rf ./*

or simply
rm -rf *

respiranto · 2015-09-30 17:06:20

berbae wrote:

So for me the right command is:
rm -rf ./*
or simply
rm -rf *

I think, what he wanted to achieve is to delete any hidden files, i.e. those that start with a dot.
To exclude '.' and '..' the regular expression '.[!.]*' can be used.

By the way, is that actually a regular expression? In sed, that would be '\.[^\.].*'

berbae wrote:

rm -rf ~/.config/xfce4* <------not correct
rm -rf ~/.config/xfce4/* <------correct

Again, I think you misunderstood the intention of the author:

$ ls -d1 ~/.config/xfce4*
/home/user/.config/xfce4
/home/user/.config/xfce4-dict
/home/user/.config/xfce4-session

scar · 2015-09-30 17:24:42

Sorry, I will reformulate the question againy because only respiranto catched the real meaning of my post in his first answer - if I was not precise enough, then it's my fault - sorry.

It is not the way I delete my files which is important.
It is the fact, than even if my dotfiles (all my .something files in my home directory, I mean ALL OF THEM) are deleted, with no active graphical session, from a tty shell, the next time I launch X, my xfce4 configuration files are like restored.

Basically, if I delete every (wm-related) config file, it has no effect at all.

The questions:

How can it be that I delete a configuration file/dir and it does not seem to have any effect?
Can we consider this as a CORRECT behaviour? (As the user should have the possibility to DELETE or EDIT his dotfiles without having the need to access any other, maybe protected parts of the filesystem)
Since when the system changed this kind of behaviour?

PS: I've tried it only with the xfce and gnome desktops - delete everything -> relaunch X -> "basicly unchanged" desktop
I gave a try to lxde too, which is behaving correctly - delete everything -> relaunch X -> "blank/new" desktop

Last edited by scar (2015-09-30 17:27:39)

respiranto · 2015-09-30 20:04:39

I have noticed that after reboot, everything is actually reset.
So the settings are stored somewhere temporarily.
/tmp does contain some files from the test user, however, they are not the issue.

Therefore I searched for files owned by the user: https://ptpb.pw/tPbE, which does not help me much.

Removing the socket file /run/user/1002/bus for some reason disables the strange behavior permanently.
However this is probably not helpful, since a socket can't be the actual reason.
Removing it simply disables some functionality.
Certainly it is not a good idea to do this with a non-test-account.

Edit 0:
I also noticed, that killing any process run by the user, after he is logged out, prevents the issue from arising.

Edit 1:
Found it:
/usr/lib/xfce4/xfconf/xfconfd

So the configuration is simply stored in the memory of that process.

What I still wonder about, is why there are still processes running after a user has logged out - most notably 'systemd --user'. Killing the latter kills most of the other, except for ssh-agent and gpg-agent.

Last edited by respiranto (2015-09-30 20:24:26)

scar · 2015-10-01 13:17:44

Well, I am using only xfce but it will be the same for gnome users too. I tested with kde - it is not affected!

The main problem for me is:

From a correct philosophical point of view, I should have the possibility to edit/delete my config files manually any time I want.
It is like having an apache config, which you want to delete and rebuild from scratch, but it resurrects itself always with the old config from some dark corner of the filesystem.
Does not look very correct to me.

Does anybody know, what is causing this stupid behavior?

respiranto · 2015-10-01 13:52:26

scar wrote:

Does anybody know, what is causing this stupid behavior?

See my 'Edit 1' in the post above:

Edit 1:
Found it:
/usr/lib/xfce4/xfconf/xfconfd
So the configuration is simply stored in the memory of that process.
What I still wonder about, is why there are still processes running after a user has logged out - most notably 'systemd --user'. Killing the latter kills most of the other, except for ssh-agent and gpg-agent.

toz · 2015-10-01 14:28:07

It looks like the session is not being terminated after logout.

loginctl list-sessions

...still shows the session as active after logout.

Running:

loginctl terminate-session <SESSION_ID>

...terminates all of the user processes.

According to "man pam_systemd":

On logout, this module ensures the following:
1. If enabled in logind.conf(5), all processes of the session are
terminated. If the last concurrent session of a user ends, the
user's systemd instance will be terminated too, and so will the
user's slice unit.
2. If the last concurrent session of a user ends, the $XDG_RUNTIME_DIR
directory and all its contents are removed, too.

So it looks like pam_systemd doesn't finish its job because a user session still exists.

A couple of workarounds:
1. Enable "KillUserProcesses=yes" in /etc/systemd/logind.conf, but this comes with some warnings:

Note that setting KillUserProcesses=1 will break tools like screen(1).

2. An ~/.xinitrc script like this one (that runs loginctl terminate-session) seems to work:

#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then
    xrdb -merge $sysresources
fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then
    xrdb -merge "$userresources"
fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

mv ~/.xsession-errors ~/.xsession-errors.old
startxfce4 > ~/.xsession-errors 2>&1

loginctl terminate-session $(loginctl list-sessions | grep $USER | awk '{ print $1 }')

respiranto · 2015-10-01 14:44:29

I just tested with my backup system from 2015-06-22 and surprisingly after logging out as the test user,
only three processes are left: 'systemd --user' and two other, not including xfconfd, i.e. the settings are not kept after removal of the relevant files.

scar · 2015-10-01 17:16:10

So, there was an update, somewhere, somehow that changed the behaviour of loginctl? Or what?
Why are only gnome and xfce affected and not kde or lxde, for example?

respiranto · 2015-10-01 17:18:02

scar wrote:

Why are only gnome and xfce affected and not kde or lxde, for example?

Because they probably don't have a true equivalent to xfconfd, i.e. a process that stores the configuration in its internal memory.

scar · 2015-10-01 17:34:55

Enabling KillUserProcesses=yes in /etc/systemd/logind.conf seems to work.

By the way, the deletion of the dotfiles is only working after effective logout of the user; and if deleting as root/other user with rights to do it.

Last edited by scar (2015-10-01 17:36:05)

respiranto · 2015-10-01 17:38:45

scar wrote:

Enabled KillUserProcesses=yes in /etc/systemd/logind.conf seems to work.
By the way, the deletion of the dotfiles is only working after effective logout of the user; and if deleting as root/other user with rights to do it.

Setting KillUserProcesses to yes will force any user process to stop after he logged out, so xfconfd will elsewise still be running.

scar · 2015-10-01 18:35:52

OK. How can xfconfd run without X? Is it not something that has to switch off after any kind of X session is finished?
Is it only strange for me? (Really sorry, there is a word I want to use instead of strange, but I can't, this is a forum and I stay polite)

Arch Linux

#1 2015-09-29 18:37:25

Some really strange desktop session behaviour (xfce,but not only)

#2 2015-09-30 08:14:35

Re: Some really strange desktop session behaviour (xfce,but not only)

#3 2015-09-30 13:30:13

Re: Some really strange desktop session behaviour (xfce,but not only)

#4 2015-09-30 14:53:40

Re: Some really strange desktop session behaviour (xfce,but not only)

#5 2015-09-30 17:06:20

Re: Some really strange desktop session behaviour (xfce,but not only)

#6 2015-09-30 17:24:42

Re: Some really strange desktop session behaviour (xfce,but not only)

#7 2015-09-30 20:04:39

Re: Some really strange desktop session behaviour (xfce,but not only)

#8 2015-10-01 13:17:44

Re: Some really strange desktop session behaviour (xfce,but not only)

#9 2015-10-01 13:52:26

Re: Some really strange desktop session behaviour (xfce,but not only)

#10 2015-10-01 14:28:07

Re: Some really strange desktop session behaviour (xfce,but not only)

#11 2015-10-01 14:44:29

Re: Some really strange desktop session behaviour (xfce,but not only)

#12 2015-10-01 17:16:10

Re: Some really strange desktop session behaviour (xfce,but not only)

#13 2015-10-01 17:18:02

Re: Some really strange desktop session behaviour (xfce,but not only)

#14 2015-10-01 17:34:55

Re: Some really strange desktop session behaviour (xfce,but not only)

#15 2015-10-01 17:38:45

Re: Some really strange desktop session behaviour (xfce,but not only)

#16 2015-10-01 18:35:52

Re: Some really strange desktop session behaviour (xfce,but not only)

Board footer