| View previous topic :: View next topic |
| Author |
Message |
dmoreno
n00b
Joined: 01 Feb 2004
Posts: 60
|
 Posted: Mon May 03, 2021 2:39 pm Post subject: First logged in user can't start X |
 |
|
For more than one month now I've been experiencing the following problem on my Gentoo:
The first user who logs in gets the following error message when running startx:
| Code: | X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
Build Operating System: Linux 5.10.27-gentoo x86_64 Gentoo
Current Operating System: Linux sisifo 5.10.27-gentoo #1 SMP PREEMPT Fri Apr 2 19:15:07 CEST 2021 x86_64
Kernel command line: root=PARTUUID=3e23a941-4579-4bc6-88d7-b745807abb4b ro dolvm rootfstype=ext4 scsi_mod.use_blk_mq=1 i915.fastboot=1 libahci.ignore_sss=1 hugepagesz=2M hugepages=1 transparent_hugepage=madvise snd_hda_intel.enable=1 snd_hda_intel.index=0 cx88_alsa.enable=1 cx88_alsa.index=2 init=/lib/systemd/systemd loglevel=3 udev.log-priority=3 intel_iommu=igfx_off vt.default_red=0x07,0xdc,0x85,0xb5,0x26,0xd3,0x2a,0xee,0x00,0xcb,0x65,0x58,0x93,0x6c,0x83,0xfd vt.default_grn=0x36,0x32,0x99,0x89,0x8a,0x36,0xa1,0xe8,0x2b,0x4b,0x7b,0x6e,0xa1,0x71,0x94,0xf6 vt.default_blu=0x42,0x2f,0x00,0x00,0xd2,0x82,0x98,0xd5,0x36,0x16,0x83,0x75,0xa1,0xc4,0x96,0xe3 vt.color=0x70 nohugeiomap mds=full,nosmt systemd.unified_cgroup_hierarchy=true BOOT_IMAGE=/vmlinuz-5.10.27-gentoo root=UUID=02570abf-521d-407d-a98d-4a915f3212a8 ro
Build Date: 14 April 2021 08:02:04PM
Current version of pixman: 0.40.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/david/.local/share/xorg/Xorg.1.log", Time: Mon May 3 16:14:21 2021
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE)
Fatal server error:
(EE) xf86OpenConsole: Cannot open virtual console 3 (Permission denied)
(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/home/david/.local/share/xorg/Xorg.1.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error |
However, next logged-in user (it can be the same user), as well as the following logged-in users, are able to start X with no issues at all.
I'm not completely sure when it started to happen, but it could be after a package upgrade which included systemd-247.2-r4.
Does anyone have any clue about the possible cause?
Thanks.
P.S.: As implied by the above description, I'm using a systemd-based Gentoo with default runlevel 3. There are further details about my system on the X log message. Please tell me if you need some additional information. |
|
| Back to top |
|
 |
redfish
n00b
Joined: 27 Apr 2021
Posts: 22
|
| Posted: Mon May 03, 2021 10:16 pm Post subject: |
|
|
Is there any useful info in the Xorg log file? /home/david/.local/share/xorg/Xorg.1.log
If not, to debug further, you could strace to see which exact syscall (probably file-related) is failing with permission-denied. If it indeed trying to open a device file (in /dev) and failing, then this will catch it:
| Code: |
strace -f -e trace=file -o /tmp/startx.log startx
|
Look in /tmp/startx.log for EPERM, probably near the end and note the path. Then, if the culprit is found, then perhaps check permission bits on that file. Since you say that startx works the second time around, perhaps something changes the permissions. But, jumping ahead. |
|
| Back to top |
|
|
redfish
n00b
Joined: 27 Apr 2021
Posts: 22
|
| Posted: Mon May 03, 2021 11:34 pm Post subject: |
|
|
Just a wild guess, but from info in another thread, this issue might be related to systemd-logind:
https://forums.gentoo.org/viewtopic-p-8606310.html#8606310
| GDH-gentoo wrote: | | redfish wrote: | | FWIW, on Arch I'm running Xorg as a normal user, and it doesn't have the +s permission bit set. |
Xorg needs a logind provider to run as a normal user. Arch is a systemd distribution, so you'd have systemd-logind running automatically after boot, and filling that role. |
|
|
| Back to top |
|
|
dmoreno
n00b
Joined: 01 Feb 2004
Posts: 60
|
| Posted: Sat May 08, 2021 3:13 pm Post subject: |
|
|
Thanks, redfish, for your replies.
Xorg log file didn't have any useful information about the error, apart from the error messages I posted. No other EE messages, or relevant WW messages.
Strace didn't provide much useful information either. The only difference between a failed startx attempt and a successful one is the following:
| Code: | < --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=0000, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
< wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 0
< wait4(-1, 0x000000, WNOHANG, NULL) = -1 ECHILD (No child processes)
< rt_sigreturn({mask=[PIPE]}) = 0
125a122
> wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 0
127a125,127
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=0000, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
> wait4(-1, 0x000000, WNOHANG, NULL) = -1 ECHILD (No child processes)
> rt_sigreturn({mask=[PIPE]}) = 0
|
"<"-decorated lines correspond to the successful attempt, while ">"-decorated lines correspond to the failed one. PIDs are not real.
As for systemd-logind, it's loaded, active and running. |
|
| Back to top |
|
|
dmoreno
n00b
Joined: 01 Feb 2004
Posts: 60
|
| Posted: Sat May 08, 2021 4:34 pm Post subject: |
|
|
I now realise that I posted the diff of plain strace outputs.
I've re-issued the strace command with the suggested flags and this is the only relevant line I could find:
| Code: |
4290 openat(AT_FDCWD, "/dev/tty2", O_RDWR|O_NONBLOCK) = -1 EACCES (Permission denied)
|
It's certainly consistent with the error message but I guess it doesn't provide much information.
Anyway, I'm exploring other paths, and I think they're promising.
In particular I'm checking the output of several loginctl commands.
I'm posting here some of them.
loginctl list-sessions in failed session:
loginctl list-sessions in successful session:
| Code: |
SESSION UID USER SEAT TTY
3 1000 david seat0 tty2
1 sessions listed.
|
loginctl list-users in failed session:
loginctl list-users in successful session:
| Code: | UID USER
1000 david
1 users listed.
|
I've never got acquainted with that systemd stuff, but maybe someone can give some clues here. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Sat May 08, 2021 4:59 pm Post subject: |
|
|
That loginctl output looks promising to me. If logind does not think you exist, then I would expect the type of problems you reported here. The question then turns to why logind thinks you do not exist, but eventually starts working. In every prior thread I have seen with logind problems, the issue was some sort of configuration problem, and logind persistently ignored the user until the administrator, with help from the forum, found and fixed that configuration problem. No amount of rebooting, logging in/out etc. would help in those cases. Yet here, a bit of user persistence gets past the error.
For elogind, and I assume for systemd-logind as well, the login daemon is notified of your existence by a PAM hook. I would start by inspecting grep -r logind /etc/pam.d/. If that turns up nothing, review the full contents of each of the pam configuration files that is relevant to how you log in. |
|
| Back to top |
|
|
dmoreno
n00b
Joined: 01 Feb 2004
Posts: 60
|
| Posted: Sun May 09, 2021 10:53 am Post subject: |
|
|
Thanks for your reply, Hu.
I certainly can't find "logind" on my /etc/pam.d, but I don't think I've ever had something like that. Are you sure this is something that applies to systemd too?
Anyway, I'll try to thoroughly review my pam configuration files, since I think we're now much closer to solve the problem. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Sun May 09, 2021 4:04 pm Post subject: |
|
|
| dmoreno wrote: | | Are you sure this is something that applies to systemd too? |
No. I guessed that it would apply since elogind is based on extracted code from systemd-logind, but I have neither experience nor documentation stating such. I've never needed to get systemd-logind to behave. |
|
| Back to top |
|
|
redfish
n00b
Joined: 27 Apr 2021
Posts: 22
|
| Posted: Sun May 16, 2021 12:35 am Post subject: |
|
|
| dmoreno wrote: |
| Code: |
4290 openat(AT_FDCWD, "/dev/tty2", O_RDWR|O_NONBLOCK) = -1 EACCES (Permission denied)
|
It's certainly consistent with the error message but I guess it doesn't provide much information.
|
Yeah, so that caught the symptom in a bit more detail. Did you try monitoring the permissions/group on /dev/tty2? Do the permissions change between first session and next session? If permissions change, then what changes them -- perhaps this might suggest some investigation directions. Also, are these sessions being opened in the same tty, in sequence; or are the sessions concurrent on different ttys?
That said, maybe you don't need to dig deeper into the symptom though, because you already found that systemd-logind is ultimately closer to the root cause. |
|
| Back to top |
|
|
SlashBeast
Retired Dev
Joined: 23 May 2006
Posts: 2922
|
| Posted: Tue May 18, 2021 4:56 pm Post subject: |
|
|
Take a look at https://wiki.gentoo.org/wiki/Non_root_Xorg
If you have no elogind integration in /etc/pam* then most likely you've discarded the configuration files update.
You can run emerge with '--noconfmem' and rebuild packages that installs into /etc/pam.d, like:
| Code: | | emerge -1 --noconfmem pambase |
And then run dispatch-conf after it. You can use 'qfile /etc/pam.d' to see what packages installed files there, qfile is provided by portage-utils |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
