Created attachment 9729 [details]
journal snippet

Doesn't happen here with a new user "xterm" (but I get Xfce4 updates from wally's Copr repo for Xfce4)

Assuming lib(64)glib2.0_0 is a base system package, because I can't remove it here without removing basesystem-minimal, so assigning to the base system maintainers. 

@ Jani

I'm only guessing the issue is with glib2.0, so CC'ing you in case it's an Xfce bug.

CC: (none) => jani.valimaa, kernel, marja11
Source RPM: (none) => glib2.0, xfce4-sesion
Summary: new xfce user DE starup crashes => new xfce user DE startup crashes (kernel: traps: xfce4-session[6764] trap int3 ip:7fd2c7934471 sp:7ffc235f7b10 error:0 in libglib-2.0.so.0.5400.1[7fd2c78e5000+110000])
Assignee: bugsquad => basesystem

I can't reproduce this, but I do have up to date system/Xfce and use lightdm as display manager.

Official pkgs from Core media are newer than ones from Xfce4 Copr repo.

Env variables with lightdm + Xfce:

$ env |grep XDG |sort
XDG_CONFIG_DIRS=/etc/xdg
XDG_CURRENT_DESKTOP=XFCE
XDG_DATA_DIRS=/usr/local/share:/usr/share
XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/xtest
XDG_MENU_PREFIX=xfce-
XDG_RUNTIME_DIR=/run/user/1001
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SEAT=seat0
XDG_SESSION_DESKTOP=xfce
XDG_SESSION_ID=5
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
XDG_SESSION_TYPE=x11
XDG_VTNR=1

(In reply to Bit Twister from comment #0)
> Description of problem:
> Created a new user test account (xterm)
> after ssdm login, xfce DE starts running stuff in ~/.config, crashes, and
> returns me to the sddm login screen.
> 

Please check the permissions for ~/.config (and for other dirs and files in $HOME).

I am soooo sorry for wasting everyone's time.

It was indeed user induced problem. I have created /etc/skel/.config with some of the preset values I want in new accounts.

Before values
drw-r--r--  2 xterm xterm 4.0K Oct 13 11:30 autostart
drwx------  6 xterm xterm 4.0K Mar 28  2017 geany
drwx------  2 xterm xterm 4.0K Oct 13 18:59 gtk-3.0
drwxr-xr-x  2 xterm xterm 4.0K Oct 13 11:28 local
drw-r--r--  2 xterm xterm 4.0K Dec 17  2016 orage
drwx------  2 xterm xterm 4.0K Oct 12 16:46 pulse
drw-r--r--  2 xterm xterm 4.0K Oct  5  2016 shutdown
drwxrwxr-x  2 xterm xterm 4.0K Oct 12 16:46 Thunar
-rw-------  1 xterm xterm  597 Oct 12 16:46 user-dirs.dirs
-rw-rw-r--  1 xterm xterm    5 Oct 12 16:46 user-dirs.locale
drw-r--r--  5 xterm xterm 4.0K Mar 15  2017 xfce4

$ cd xfce4
drw-r-xr-x  5 xterm xterm 4.0K Mar 15  2017 .
drwxr-xr-x 11 xterm xterm 4.0K Oct 12 16:46 ..
drwx------  2 xterm xterm 4.0K Jul  6 04:18 desktop
-rw-r--r--  1 xterm xterm   47 Jul  1 20:11 helpers.rc
drwxr-xr-x  2 xterm xterm 4.0K Jul  6 04:18 panel
drwxr-xr-x  2 xterm xterm 4.0K Mar 26  2017 terminal


Fix was to set 755 on all the ~xterm/.config directories.

Since xfce4, will create ~/.config/xfce4 directories upon start up, I would think the code should always set the desired perms.


You get to decide if you want to marked this resolved.

Actually I should have said that check the ownership of ~/.config with 'ls -lhd ~/.config'.

I think it's something else than 'xterm'. There shouldn't be any need to give rights for other users than yourself. Everything should work with 700 rights for ~/.config and all dirs/files under it.

(In reply to Jani Välimaa from comment #7)
> Actually I should have said that check the ownership of ~/.config with 'ls
> -lhd ~/.config'.
> 
> I think it's something else than 'xterm'. There shouldn't be any need to
> give rights for other users than yourself. Everything should work with 700
> rights for ~/.config and all dirs/files under it.

Or actually 700 for directories and executables and 600 for other files.

Ok, 700 works. I wiped the xterm account, rsync'ed /etc/skel/ /home/xterm
chown -R xterm:xterm /home/xterm

and logged in without problem.

Still your call what to do about this bug resolution.

You should not use rsync with files/dirs in /etc/skel. adduser/useradd cmd copies all from /etc/skel with correct owner/rights to newly created user's $HOME (unless you especially skip that).

I'm closing this as INVALID.

Status: UNCONFIRMED => RESOLVED
Resolution: (none) => INVALID