You are not logged in.
Last week, suddenly when I login-ed into GDM, it kicked me back to its login screen. I thought maybe last night's update caused this. So I waited for a few days and did pacman -Syu every day but it did not help. Then I tried SDDM and XDM and both had the same behavior. So far I am using the tty + ~/.xinitrc to login and have disabled all the display managers but I want the GDM back. Any ideas how to solve this problem?
Last edited by arnuld (2022-06-30 09:13:21)
Offline
That's typically indicative of your session crashing (ie. not a problem w/ the DM itself), start by looking for the session process errors/segfaults at the system journal.
Offline
Do you mean journalctl --system I should check?
Offline
Since out put from journalctl is long. Here are some snippets I took:
AT-SPI: Could not obtain desktop path or name
Jun 25 23:59:00 arch64 gnome-shell[24999]: AT-SPI: Could not obtain desktop path or name
Jun 25 23:59:00 arch64 at-spi-bus-launcher[24955]: dbus-daemon[24955]: Activating service name='org.a11y.atspi.Registry' requested by ':1.1' (uid=1000 pid=24999 comm="/usr/bin/gnome-shell")
Jun 25 23:59:00 arch64 at-spi-bus-launcher[25943]: Invalid MIT-MAGIC-COOKIE-1 key
Jun 25 23:59:00 arch64 at-spi2-registr[25943]: Could not open X display
Jun 25 23:59:00 arch64 dbus-daemon[24867]: [session uid=1000 pid=24867] Successfully activated service 'org.freedesktop.portal.Desktop'
Jun 25 23:59:00 arch64 systemd[809]: Started Portal service.
Jun 25 23:59:00 arch64 at-spi-bus-launcher[24955]: dbus-daemon[24955]: Successfully activated service 'org.a11y.atspi.Registry'
Jun 25 23:59:00 arch64 gnome-shell[24999]: Can't update stage views actor <overviewGroup>[<StWidget>:0x55b00052f9d0] is on because it needs an allocation.
Jun 25 23:59:00 arch64 gnome-shell[24999]: Can't update stage views actor <overview>[<Gjs_ui_overview_OverviewActor>:0x55b00109ec20] is on because it needs an allocation.
Jun 25 23:59:00 arch64 gnome-shell[24999]: Can't update stage views actor <unnamed>[<Gjs_ui_overviewControls_ControlsManager>:0x55b0010a3640] is on because it needs an allocation.
Jun 25 23:59:00 arch64 gnome-shell[24999]: Can't update stage views actor <unnamed>[<Gjs_ui_workspacesView_WorkspacesDisplay>:0x55b00119f2c0] is on because it needs an allocation.
Jun 25 23:56:22 arch64 gsd-media-keys[24557]: Unable to get default sink
Jun 25 23:56:22 arch64 gsd-media-keys[24557]: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
Jun 25 23:56:22 arch64 gsd-media-keys[24557]: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
Jun 25 23:56:24 arch64 gnome-shell[24434]: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
Jun 25 23:56:24 arch64 gnome-shell[24434]: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
Jun 25 23:56:24 arch64 wireplumber[1028]: can't open control for card hw:0: No such file or directory
Jun 25 23:56:24 arch64 wireplumber[1028]: [string "alsa.lua"]:344: attempt to index a nil value (local 'device')
stack traceback:
[string "alsa.lua"]:344: in function <[string "alsa.lua"]:342>
Jun 25 23:56:24 arch64 wireplumber[1028]: Card can't get card_name from card_index 1
Jun 25 23:56:24 arch64 systemd[1]: Started Getty on tty3.
Jun 25 23:56:24 arch64 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=getty@tty3 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun 25 23:56:24 arch64 kernel: audit: type=1130 audit(1656181584.102:246): pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=getty@tty3 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun 25 23:56:24 arch64 wireplumber[1028]: can't open control for card hw:1: No such file or directory
Jun 25 23:56:24 arch64 wireplumber[1028]: dbus[1028]: Attempted to unregister path (path[0] = MediaEndpoint path[1] = A2DPSink) which isn't registered
Jun 25 23:56:24 arch64 wireplumber[1028]: dbus[1028]: Attempted to unregister path (path[0] = MediaEndpoint path[1] = A2DPSink) which isn't registered
Jun 25 23:56:24 arch64 wireplumber[1028]: dbus[1028]: Attempted to unregister path (path[0] = MediaEndpoint path[1] = A2DPSink) which isn't registered
Offline
sudo journalctl -b | curl -F 'file=@-' 0x0.st
Offline
sudo journalctl -b | curl -F 'file=@-' 0x0.st
Offline
Jun 26 12:40:00 arch64 login[614]: LOGIN ON tty1 BY arnuld
Looks like you started gnome via startx/xinit
Jun 26 12:40:03 arch64 gnome-session[945]: gnome-session-binary[945]: WARNING: Could not get session id for session. Check that logind is properly installed and pam_systemd is getting used at login.
Jun 26 12:40:03 arch64 gnome-session-binary[945]: WARNING: Could not get session id for session. Check that logind is properly installed and pam_systemd is getting used at login.
and also like your xinitrc is broken (last link below)
The journal needs to cover a bad DM login attempt, eg. "sudo journalctl -b -1" for the previous boot.
Offline
Okay, I started the gdm.service and then rebooted. GDM asked for password but, as usual, could not log-in. I went to tty2 and did startx there and ran the command:
Last edited by arnuld (2022-06-26 09:05:43)
Offline
Jun 26 14:00:56 arch64 systemd-logind[574]: New session 1 of user arnuld.
…
Jun 26 14:01:11 arch64 sudo[858]: arnuld : TTY=tty1 ; PWD=/home/arnuld ; USER=root ; COMMAND=/usr/bin/systemctl enable gdm
…
Jun 26 14:01:16 arch64 systemd[1]: Reached target System Shutdown.
That journal is from a boot where you logged in on TTY1, enabled GDM and then shut down - the next boot is probably the one you wanted to post.
Offline
Jun 26 14:00:56 arch64 systemd-logind[574]: New session 1 of user arnuld. … Jun 26 14:01:11 arch64 sudo[858]: arnuld : TTY=tty1 ; PWD=/home/arnuld ; USER=root ; COMMAND=/usr/bin/systemctl enable gdm … Jun 26 14:01:16 arch64 systemd[1]: Reached target System Shutdown.
That journal is from a boot where you logged in on TTY1, enabled GDM and then shut down - the next boot is probably the one you wanted to post.
Okay, let's see. This down here is what you think is right? If not, guide me and I will post a new one.
Last edited by arnuld (2022-06-28 17:55:24)
Offline
Jun 28 22:25:28 arch64 systemd[1]: Started Session 1 of User gdm.
…
Jun 28 22:25:33 arch64 systemd[1]: Started Getty on tty2.
…
Jun 28 22:25:39 arch64 systemd-logind[542]: New session 3 of user arnuld.
…
Jun 28 22:25:39 arch64 systemd[1]: Started Session 3 of User arnuld.
…
Jun 28 22:25:44 arch64 gnome-shell[1306]: Registering session with GDM
…
Jun 28 22:25:43 arch64 chromium[1524]: Theme directory 32@2x/devices of theme Vimix-Beryl has no size field
…
Jun 28 22:25:43 arch64 firefox.desktop[1539]: ATTENTION: default value of option mesa_glthread overridden by environment.
…
Jun 28 22:25:44 arch64 gnome-shell[1306]: GNOME Shell started at Tue Jun 28 2022 22:25:42 GMT+0530 (India Standard Time)
…
Jun 28 22:25:42 arch64 dbus-daemon[1234]: [session uid=1000 pid=1234] Successfully activated service 'org.gnome.Terminal'
…
Jun 28 22:27:09 arch64 sudo[3260]: arnuld : TTY=pts/4 ; PWD=/home/arnuld ; USER=root ; COMMAND=/usr/bin/journalctl -b
Jun 28 22:27:09 arch64 audit[3260]: CRED_REFR pid=3260 uid=1000 auid=1000 ses=4 subj==unconfined msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/4 res=success'
This one shows you logging in from GDM, starting chromium, firefox, … and gnome-terminal and running "sudo journalctl -b" in a PTS (most likely gnome-terminal)
This is somehow not consistent w/ the problem described in your OP?
Though for
Jun 28 22:25:41 arch64 gnome-session[1287]: gnome-session-binary[1287]: WARNING: Could not get session id for session. Check that logind is properly installed and pam_systemd is getting used at login.
Jun 28 22:25:41 arch64 gnome-session-binary[1287]: WARNING: Could not get session id for session. Check that logind is properly installed and pam_systemd is getting used at login.
and TTY2 I assume you had GDM running on TTY1 and then opened TTY2 and ran startx from there?
But there's no trace of an attempt to login from GDM.
Offline
.. SNIP..
I assume you had GDM running on TTY1 and then opened TTY2 and ran startx from there?
But there's no trace of an attempt to login from GDM.
I tried to login. just now Here is the journal output: http://0x0.st/oS04.txt
EDIT:
Looks like there are many who have been complaining about this since 2020.
https://bbs.archlinux.org/viewtopic.php?id=258297 (check post #8)
Found these 2 links. Will read them, maybe it's time to switch to newer methods. Everything is slowly being taken over by systemd:
https://wiki.archlinux.org/title/Systemd-homed
https://systemd.io/CONVERTING_TO_HOMED/
Last edited by arnuld (2022-06-29 19:10:25)
Offline
nothing about homed will automatically break your session that hasn't been using homed yet. You can ignore the homed service errors, they aren't the cause.
Your actual problem is this
/home/arnuld/.profile: line 1: /home/arnuld/.cargo/env: No such file or directory
you have a broken .profile referencing things that don't exist.
Offline
Though there's probably worse in there (exit/exec lines, possibly in relation to a console autologin/startx)
If you can't spot the errorneous exit yourself, post that file and also possibly ~/.xprofile
Offline
Both ~/.profile and ~/.xsession_errors had only one line of text in them, the same text you posted above. Also, ~/.xprofile does not exist. I installed Rust programming language once. It did that ".cargo" thing. Later I removed the Rust but looks like not everything went back to normal. I have removed both ~/.profile and ~/.xsession_errors. On next reboot I could login into GDM. I did not know a linen of text in ~/.profile could cause this much of problem.
Many thanks for the help. One good thing that came out from this is I came to know about homed. Will read about it more and switch to it this weekend.
Last edited by arnuld (2022-06-30 09:07:28)
Offline
OOC, can you say what the line *exactly* was?
I can see where you could pre-emptively terminate the session w/ those files being sourced, but if GDM kills the session because of some random unrelated command failure, that would be good to know.
Offline
OOC, can you say what the line *exactly* was?
I can see where you could pre-emptively terminate the session w/ those files being sourced, but if GDM kills the session because of some random unrelated command failure, that would be good to know.
It was exactly what @V1del said in post #13 above. My ~/.profile had just one that line in it.
I was taken by a bit of surprise though for I thought one broken line of text can make all Display Managers behave weirdly. Compare that with general thinking that operating systems have become more resilient over time. Do they :-P
Last edited by arnuld (2022-07-01 05:19:39)
Offline
The line **literally** ***just*** said
/home/arnuld/.cargo/env
?
Because in that case, yes
a bit of surprise though for I thought one broken line of text can make all Display Managers behave weirdly
except "all Display Managers" would more likely be GDM and that behavior idiotic.
A random invalid session setup command should™ not terminate the session.
Offline
All display managers means XDM, SDDM and GDM. I have tested all three. Yes, I do understand that it feels so weird that some piece of random/broken text was causing login failures. It is just that it is true.
Offline
The line **literally** ***just*** said
/home/arnuld/.cargo/env
?
What's your users shell?
Is /bin/sh bash?
Did you somehow enable pipefail?
Offline
[arnuld@arch64 ~]$ echo $SHELL
/bin/bash
I don't even know what "pipefail" means. How you want me to check it?
Offline
set -o | grep pipe
Offline
[arnuld@arch64 ~]$ set -o | grep -i pipe
pipefail off
[arnuld@arch64 ~]$
Offline
Nope.
If you have just one line in ~/.profile that only says "false", does the GDM login still fail?
Offline
I tried with ~/false and with "~/false/env" as the only line of text in ~/.profile but not just GDM but SDDM too logs-in fine now. I wonder why it was causing issue earlier :-\
Offline