Ask Your Question

XFCE login stuck

asked 2019-01-22 14:10:58 -0500

Ben Collver gravatar image

updated 2019-01-24 10:42:53 -0500

I tried to log in to a brand new user account named "tylx". I get past the login screen, and then get stuck with a desktop background and a mouse pointer. The desktop environment is missing. A reboot doesn't help. I can log in as "ben", but not as "tylx". I created the "tylx" account using Fedora's system-config-users menu option "Users and Groups". "tylx" is in the wheel group. I am running Fedora 29 x64, XFCE spin.

Diagnostic information is included at the bottom of this message. This information leads me to believe that the problem is related to systemd. The login manager begins to start an XFCE session for "tylx". At some point it runs /etc/X11/xinitr/xinitrc.d/, which runs "systemctl --user import-environmentt DISPLAY XAUTHORITY", which logs an error "Access denied".

I have not spent much time debugging systemd, and count not find helpful troubleshooting information in the systemctl man page.

Any suggestions how to diagnose this problem further?



# ps faux | grep tylx
tylx      4134  0.0  0.0 216468  3600 ?        Ss   11:26   0:00      \_ /usr/bin/bash /etc/X11/xinit/Xsession startxfce4
tylx      4168  0.0  0.0 230508  6164 ?        S    11:27   0:00          \_ systemctl --user import-environment DISPLAY XAUTHORITY
tylx      4131  0.0  0.0 372736  3980 ?        Sl   11:26   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
tylx      4143  0.0  0.0  16488   404 ?        S    11:26   0:00 dbus-launch --sh-syntax --exit-with-session
tylx      4158  0.0  0.0  34436  2156 ?        Ssl  11:26   0:00 /usr/bin/dbus-daemon --syslog --fork --print-pid 6 --print-address 8 --session

# cat /home/tylx/.xsession-errors
Failed to import environment: Access denied

Thanks for that suggestion villykruse, i am including shell output below. Does this mean anything to you? Thanks again, -Ben

# id tylx
uid=65535(tylx) gid=65535(tylx) groups=65535(tylx),10(wheel)

# systemctl status user@65535
● user@65535.service - User Manager for UID 65535
   Loaded: bad-setting (Reason: Unit user@65535.service has a bad unit file setting.)
   Active: inactive (dead)
     Docs: man:user@.service(5)

Jan 24 08:35:11 ahimsa systemd[1]: /usr/lib/systemd/system/user@.service:9: Invalid user/group name or numeric ID: 65535
Jan 24 08:35:11 ahimsa systemd[1]: user@65535.service: Unit configuration has fatal error, unit will not be started.

# systemctl status user@tylx
● user@tylx.service - User Manager for UID tylx
   Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:user@.service(5)

edit retag flag offensive close merge delete


It is a bit of a shot in the dark, but you might check to see if you are getting any SELinux denials/errors. There are probably several ways to look at these, but one simple way is to run sudo audit2why -a (where -a causes the program to get its input from the audit and message logs). audit2why is in the policycoreutils-python-utils software package (run sudo dnf install policycoreutils-python-utils if it isn't installed already). This tries to give somewhat human readable explanations of any SELinux denials.

psg_nm gravatar imagepsg_nm ( 2019-01-23 01:22:32 -0500 )edit

Run systenctl status user@1001 assuming that the user id for tylx is 1001. If the id is something else, replace 1001. systemd for the user session should have heen started, but it wasn't.

villykruse gravatar imagevillykruse ( 2019-01-23 01:44:03 -0500 )edit

You deleter your update, but it actually hit the nail on the head.

villykruse gravatar imagevillykruse ( 2019-01-24 11:11:17 -0500 )edit

1 Answer

Sort by » oldest newest most voted

answered 2019-01-24 12:30:30 -0500

villykruse gravatar image

updated 2019-01-25 00:08:29 -0500

Based on your updates I see that you created the user with a user id of 65535 which is a magic value for invalid user id. Seen as a 16-bin integer this value is the same as -1.

It is a bit unfortunate that system-config-users would allow you to specify that number, or any other number which have been used already. As a bit of advice, let system-config-users chose the next available number, for example 1001.

There is a bug in system-config-users in that the user nobody with user id 65534 is regarded wrongly as a regular user, and therefore it takes this as the highest user id used so far. The next one will then be 65535 which is considered invalid.

For systems that has been upgraded through several fedora releases, the user 65534 is named nfsnobody, and that user name is ignored when searching for the highest user id used.

The old entries in /etc/passwd looks like that

nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin

And with these lines system-config-users works properly.

edit flag offensive delete link more


On the contrary i did no such thing. I did not specify a user id, but let system-config-users choose it. Now, when i go to add a third user, it defaults to user id 65536. Thoughts?

Ben Collver gravatar imageBen Collver ( 2019-01-24 18:13:07 -0500 )edit

You are absolutely right. This is a bug which has been reported not less than three times on bugzilla.

The problem is that user nobody used to be called nfsnobody with user id 65534. When system-config-users search for the highest used user id so far it knows to ignore nfsnobody and the user nobody is treated as a regular user.

My system has been upgraded through several fedora releases and /etc/passwd contains these lines.

nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
villykruse gravatar imagevillykruse ( 2019-01-24 23:58:24 -0500 )edit

When i specify user id 1001 at user creation, then i can log in. Thanks!

Ben Collver gravatar imageBen Collver ( 2019-01-25 11:42:19 -0500 )edit

"Should not be noticeable by users"

Ben Collver gravatar imageBen Collver ( 2019-01-25 11:42:41 -0500 )edit

Question Tools


Asked: 2019-01-22 14:08:26 -0500

Seen: 361 times

Last updated: Jan 25 '19