From: bokr@bokr.com
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: Danny Milosavljevic <dannym@scratchpost.org>, 44944@debbugs.gnu.org
Subject: bug#44944: Unable to log into X session via gdm
Date: Tue, 20 Sep 2022 16:49:57 +0200 [thread overview]
Message-ID: <20220920144957.GA10253@LionPure> (raw)
In-Reply-To: <8735crdu0p.fsf@gmail.com>
Hi Maxim,
On +2022-09-16 15:00:22 -0400, Maxim Cournoyer wrote:
> Hi,
>
> Danny Milosavljevic <dannym@scratchpost.org> writes:
>
> > The latest guix system reconfigure (of yesterday) left me unable to login into
> > my X session. guix system rollback DID NOT fix it.
> >
> > I would enter my password and it would "try" to login and return right back to
> > the gdm login screen.
> >
> > I've since removed gdm from my OS configuration (because I have to do actual
> > *work* on this computer), but I think it would have been enough to just
> > chown /var/lib/gdm and rm ~/.xsession-errors (!) in order to make it work
> > again.
> >
> > Does that mean that user ids are non-reproducible?
> >
> > Why not have user_id = hash(user_name) ? Then they *are* reproducible.
>
> That'd be cool, but how would you implement such a hash, that returns
> something fixed between 0 and 1024? That doesn't sound feasible,
> although I'm no hash function expert.
>
To "return something fixed between 0 and 1024" (1023?) In a context
with less than 1024 users, couldn't one wrap Danny's "hash(username)"
with a local function that finds a 0..1023 index into a trusted table
of hash(username) values represented as string lines?
Similar to the idea of representing 32-bit sRGB 16-million-colors+transparency
with an 8-bit pallette index -- or even a 1-bit index for fg/bg alternates
to black/white.
BTW, for the unlimited-number-of-users case, what sets the 1024 range limit?
> > (I've tried finding the spot where those user accounts are generated/updated
> > but so far have been unable to)
> >
> > Anyway, this is just to record the problem and workaround. I won't do
> > further research on this problem on it on this computer.
> >
> > The "gdm" system account is gone by now because I've removed gdm from the
> > OS configuration--and I don't plan on adding it ever again.
>
> I experienced the exact same problem as you. My topmost /var/lib/gdm
> directory has the correct permissions, but it contains stale entries
> that were created in the past by a different GDM user whose ID is no
> longer the same:
>
> --8<---------------cut here---------------start------------->8---
> /var/lib/gdm:
> total 616
> drwx------ 1 gdm gdm 46 Sep 16 09:09 .
> drwxr-xr-x 1 root root 222 May 7 20:40 ..
> drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .cache
> drwx------ 1 nixbld04 opendht 44 Dec 7 2021 .config
> -rw------- 1 955 gdm 1146880 Sep 16 09:09 core
> drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 .local
>
> /var/lib/gdm/.cache:
> total 0
> drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .
> drwx------ 1 gdm gdm 46 Sep 16 09:09 ..
> drwxr-xr-x 1 nixbld04 opendht 384 Dec 7 2021 fontconfig
> drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 ibus
> drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 mesa_shader_cache
>
> /var/lib/gdm/.cache/fontconfig:
> total 84
> drwxr-xr-x 1 nixbld04 opendht 384 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 ..
> -rw-r--r-- 1 nixbld04 opendht 18496 Dec 7 2021 23ef510a04af7dd5ac1a2dbd06c4afd1-le64.cache-7
> -rw-r--r-- 1 nixbld04 opendht 272 Dec 7 2021 269249ae71e4e445ff7f16f21dcb6de5-le64.cache-7
> -rw-r--r-- 1 nixbld04 opendht 256 Dec 7 2021 50fa4f3b9c91fead50cbfcdae3296c45-le64.cache-7
> -rw-r--r-- 1 nixbld04 opendht 50584 Dec 7 2021 a927202dec7f348d7a0569dcad9f19a8-le64.cache-7
> -rw-r--r-- 1 nixbld04 opendht 200 Dec 7 2021 CACHEDIR.TAG
>
> /var/lib/gdm/.cache/ibus:
> total 0
> drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 ..
> drwxr-xr-x 1 nixbld04 opendht 16 Dec 7 2021 bus
>
> /var/lib/gdm/.cache/ibus/bus:
> total 172
> drwxr-xr-x 1 nixbld04 opendht 16 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 ..
> -rw-r--r-- 1 nixbld04 opendht 173300 Dec 7 2021 registry
>
> /var/lib/gdm/.cache/mesa_shader_cache:
> total 36
> drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 ..
> drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 02
> drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 72
> drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 88
> drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 a3
> drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 c4
> drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 f9
> -rw-r--r-- 1 nixbld04 opendht 1310728 Dec 7 2021 index
>
> /var/lib/gdm/.cache/mesa_shader_cache/02:
> total 4
> drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 ..
> -rw-r--r-- 1 nixbld04 opendht 868 Dec 7 2021 f0edfe0ef96096640b39ff4d2786b503a60a43
>
> /var/lib/gdm/.cache/mesa_shader_cache/72:
> total 4
> drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 ..
> -rw-r--r-- 1 nixbld04 opendht 989 Dec 7 2021 7cd650943c7a3136f424df6a67c7897f922307
>
> /var/lib/gdm/.cache/mesa_shader_cache/88:
> total 4
> drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 ..
> -rw-r--r-- 1 nixbld04 opendht 755 Dec 7 2021 d03ceaeebc55f4b3c972e855775b2c21381b60
>
> /var/lib/gdm/.cache/mesa_shader_cache/a3:
> total 4
> drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 ..
> -rw-r--r-- 1 nixbld04 opendht 1187 Dec 7 2021 2d688084f93805f8921dab8d7a8de5e0f1bc66
>
> /var/lib/gdm/.cache/mesa_shader_cache/c4:
> total 4
> drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 ..
> -rw-r--r-- 1 nixbld04 opendht 523 Dec 7 2021 93ffa46c262472c8d01161a581304a790b71ff
>
> /var/lib/gdm/.cache/mesa_shader_cache/f9:
> total 4
> drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 ..
> -rw-r--r-- 1 nixbld04 opendht 742 Dec 7 2021 14f5ad63c0e5edcc46473d056d0b5e38415f99
>
> /var/lib/gdm/.config:
> total 0
> drwx------ 1 nixbld04 opendht 44 Dec 7 2021 .
> drwx------ 1 gdm gdm 46 Sep 16 09:09 ..
> drwx------ 1 nixbld04 opendht 26 Dec 7 2021 gnome-session
> drwx------ 1 nixbld04 opendht 6 Dec 7 2021 ibus
> drwx------ 1 nixbld04 opendht 500 Dec 7 2021 pulse
>
> /var/lib/gdm/.config/gnome-session:
> total 0
> drwx------ 1 nixbld04 opendht 26 Dec 7 2021 .
> drwx------ 1 nixbld04 opendht 44 Dec 7 2021 ..
> drwx------ 1 nixbld04 opendht 0 Dec 7 2021 saved-session
>
> /var/lib/gdm/.config/gnome-session/saved-session:
> total 0
> drwx------ 1 nixbld04 opendht 0 Dec 7 2021 .
> drwx------ 1 nixbld04 opendht 26 Dec 7 2021 ..
>
> /var/lib/gdm/.config/ibus:
> total 0
> drwx------ 1 nixbld04 opendht 6 Dec 7 2021 .
> drwx------ 1 nixbld04 opendht 44 Dec 7 2021 ..
> drwx------ 1 nixbld04 opendht 78 Dec 8 2021 bus
>
> /var/lib/gdm/.config/ibus/bus:
> total 4
> drwx------ 1 nixbld04 opendht 78 Dec 8 2021 .
> drwx------ 1 nixbld04 opendht 6 Dec 7 2021 ..
> -rw-r--r-- 1 nixbld04 opendht 380 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-unix-0
>
> /var/lib/gdm/.config/pulse:
> total 64
> drwx------ 1 nixbld04 opendht 500 Dec 7 2021 .
> drwx------ 1 nixbld04 opendht 44 Dec 7 2021 ..
> -rw------- 1 nixbld04 opendht 36864 Dec 7 2021 c096feaf19ce3a0a450915775e7ec8e3-card-database.tdb
> -rw------- 1 nixbld04 opendht 1 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-default-sink
> -rw------- 1 nixbld04 opendht 1 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-default-source
> -rw------- 1 nixbld04 opendht 12288 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-device-volumes.tdb
> -rw------- 1 nixbld04 opendht 696 Dec 7 2021 c096feaf19ce3a0a450915775e7ec8e3-stream-volumes.tdb
> -rw------- 1 nixbld04 opendht 256 Dec 7 2021 cookie
>
> /var/lib/gdm/.local:
> total 0
> drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 .
> drwx------ 1 gdm gdm 46 Sep 16 09:09 ..
> drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 share
>
> /var/lib/gdm/.local/share:
> total 0
> drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 ..
> drwx------ 1 nixbld04 opendht 0 Dec 7 2021 applications
> drwx------ 1 nixbld04 opendht 0 Dec 7 2021 gnome-shell
> drwxr-xr-x 1 nixbld04 opendht 82 Dec 7 2021 icc
> drwx------ 1 nixbld04 opendht 0 Dec 7 2021 sounds
> drwxr-xr-x 1 nixbld04 opendht 96 Dec 8 2021 xorg
>
> /var/lib/gdm/.local/share/applications:
> total 0
> drwx------ 1 nixbld04 opendht 0 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 ..
>
> /var/lib/gdm/.local/share/gnome-shell:
> total 0
> drwx------ 1 nixbld04 opendht 0 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 ..
>
> /var/lib/gdm/.local/share/icc:
> total 4
> drwxr-xr-x 1 nixbld04 opendht 82 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 ..
> -rw-r--r-- 1 nixbld04 opendht 1448 Dec 7 2021 edid-5add33c88281761e832ba5f60ec1628e.icc
>
> /var/lib/gdm/.local/share/sounds:
> total 0
> drwx------ 1 nixbld04 opendht 0 Dec 7 2021 .
> drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 ..
>
> /var/lib/gdm/.local/share/xorg:
> total 132
> drwxr-xr-x 1 nixbld04 opendht 96 Dec 8 2021 .
> drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 ..
> -rw-r--r-- 1 nixbld04 opendht 52932 Dec 8 2021 Xorg.0.log
> -rw-r--r-- 1 nixbld04 opendht 53878 Dec 8 2021 Xorg.0.log.old
> -rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log
> -rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log.old
> --8<---------------cut here---------------end--------------->8---
>
> We have some logic in %gdm-activation that was supposed to fix that, but
> it doesn't kick in, because it has some optimization to not recurse if
> the top dir has the correct permissions, and since d429878daf3 the top
> directory permissions are always controlled at system activation time
> (and this must happen before the gdm activation script runs).
>
> I'll follow-up with a patch that puts /var/lib/gdm on a tmpfs. This
> should avoid many pitfalls people have had.
>
> Thanks,
>
> Maxim
>
>
>
PS. WDYT..
(If there isn't a tool already available that'd make it easy to use
the one-liners pro devs can concoct off the top of their heads :)
..of having a package that would install a script
to output a reminder of stale-cache-items-in-general?
It could e.g. be triggered on login by a user
more than <some configured time> since last login,
with output similar to guile's.
As a model I notice guile seems to notice stale cached .go files,
as demoed by:
--8<---------------cut here---------------start------------->8---
$ cat is-this-stale_q
#!/usr/bin/env -S guile -s
!#
(display "Test 1: is this stale??\n")
--8<---------------cut here---------------end--------------->8---
--8<---------------cut here---------------start------------->8---
$ ./is-this-stale_q
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/bokr/BS/bs20220919_2206/./is-this-stale_q
;;; compiled /home/bokr/.cache/guile/ccache/2.2-LE-8-3.A/home/bokr/BS/bs20220919_2206/is-this-stale_q.go
Test 1: is this stale??
--8<---------------cut here---------------end--------------->8---
--8<---------------cut here---------------start------------->8---
$ ./is-this-stale_q
Test 1: is this stale??
--8<---------------cut here---------------end--------------->8---
$ fg # back to emacs for mod: s/Test 1/Test 2/
emacs -nw is-this-stale_q
--8<---------------cut here---------------start------------->8---
$ ./is-this-stale_q
;;; note: source file /home/bokr/BS/bs20220919_2206/./is-this-stale_q
;;; newer than compiled /home/bokr/.cache/guile/ccache/2.2-LE-8-3.A/home/bokr/BS/bs20220919_2206/is-this-stale_q.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/bokr/BS/bs20220919_2206/./is-this-stale_q
;;; compiled /home/bokr/.cache/guile/ccache/2.2-LE-8-3.A/home/bokr/BS/bs20220919_2206/is-this-stale_q.go
Test 2: is this stale??
--8<---------------cut here---------------end--------------->8---
--8<---------------cut here---------------start------------->8---
$ ./is-this-stale_q
Test 2: is this stale??
--8<---------------cut here---------------end--------------->8---
next prev parent reply other threads:[~2022-09-20 19:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-29 13:02 bug#44944: Unable to log into X session via gdm Danny Milosavljevic
2020-11-29 17:00 ` Marius Bakke
2020-11-29 21:20 ` Danny Milosavljevic
2022-09-16 19:00 ` Maxim Cournoyer
2022-09-16 21:03 ` Maxim Cournoyer
2022-09-20 14:49 ` bokr [this message]
2022-09-22 4:11 ` Maxim Cournoyer
2022-09-25 11:47 ` Maxime Devos
2022-09-27 0:12 ` Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220920144957.GA10253@LionPure \
--to=bokr@bokr.com \
--cc=44944@debbugs.gnu.org \
--cc=dannym@scratchpost.org \
--cc=maxim.cournoyer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.