bug#40652: GDM does not starts after April 10 system reconfigure

bug#40652: GDM does not starts after April 10 system reconfigure

[R Veera Kumar]

I am using guix.git master branch.

I did guix system reconfigure on April 10 with gnome, mate, xfce and enlightenment service-types.
It was working. And next day I again did that and gdm does not starts anymore.

Initial console says:

New session c1 of user gdm.
Removed session c1.


/var/log/messages says:

gdm: Child process -325 was already dead.


/var/log/gdm/greeter.log says:

(EE)
Fatal server error:
(EE) Cannot open log file "/var/lib/gdm/.local/share/xorg/Xorg.pid-330.log"
(EE)
(EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
(EE)
Unable to run X server

Any help would be appreciated!

Veera

bug#40652: SLIM is working though with gnome, mate, xfce and enlightenment

[R Veera Kumar]

I checked that the installed system is working with SLIM.

All gnome, mate, xfce and enlightenment are working.

Perhaps the gdm patch for 1.1.0 release is causing the problem, which
changes xsession path.

Regards,
Veera

bug#40652: Local build of gdm without gdm-xsession.patch still fails to start

[R Veera Kumar]

Tried local build of gdm using master branch without gdm-xsession.patch still
fails to start it.

Updated master to 8080c03d14ccdd7897a902966ea4aeea8dbfd359 commit
Date:   Wed Apr 15 19:44:41 2020 +0200

And done guix system reconfigure still gdm failing to start.

Regards,
Veera

bug#40652: GDM does not starts after April 10 system reconfigure

[sirgazil via Bug reports for GNU Guix]

I just pull and configured my system and get the same problem.

New session c1 of user gdm.
Removed session c1.

"/var/log/messages" shows the following messages between some ntpd messages:

Apr 15 22:31:06 localhost gdm: Child process -537 was already dead. 
Apr 15 22:35:29 localhost gdm: Child process -558 was already dead. 
Apr 15 22:39:14 localhost gdm: Child process -538 was already dead. 



$ guix describe
Generation 71	Apr 15 2020 21:34:09	(current)
  sirgazil-x 66d4b67
    repository URL: https://gitlab.com/sirgazil/guix-channel-x.git
    branch: master
    commit: 66d4b677875c84d0b7a946376cd4885f202094eb
  guix 8080c03
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 8080c03d14ccdd7897a902966ea4aeea8dbfd359


---
https://sirgazil.bitbucket.io/

bug#40652: GDM does not starts after April 10 system reconfigure

[Rene via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 191 bytes --]

Hello,

can you try the following workaround ?, consider backing up the directories before deleting.

https://lists.gnu.org/archive/html/bug-guix/2019-08/msg00020.html

I hope it works.

Rene

[-- Attachment #2: Type: text/html, Size: 525 bytes --]

bug#40652: #36924 way solves the problem for me

[R Veera Kumar]

The solution in bug #36924 solved the problem in my system.

Remove /var/lib/gdm and make a empty one instead.

Thanks Rene!

Regards,
Veera

bug#40652: #36924 way solves the problem for me

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]


R Veera Kumar <vkor@vkten.in> skribis:

> The solution in bug #36924 solved the problem in my system.
>
> Remove /var/lib/gdm and make a empty one instead.
>
> Thanks Rene!
>
> Regards,
> Veera

I don't know if it's related, but recently I had GDM crashes at boot
after reconfiguring a system using gdm-service-type (generation n) to
make it use slim-service-type instead (generation n+1), and then
reconfiguring to gdm-service-type again (generation n+2).

The problem was that the 'gdm' user id number (or group id number) was
not the same in generations n and n+2, which prevented GDM from
accessing the '/var/lib/gdm' directory.

Changing the permissions with "chown -R gdm.gdm /var/lib/gdm" or
deleting '/var/lib/gdm' to force the creation of a new one with correct
permissions allowed GDM to work correctly again.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

bug#40652: #36924 way solves the problem for me

[Ludovic Courtès]

Hi Guillaume,

Guillaume Le Vaillant <glv@posteo.net> skribis:

> I don't know if it's related, but recently I had GDM crashes at boot
> after reconfiguring a system using gdm-service-type (generation n) to
> make it use slim-service-type instead (generation n+1), and then
> reconfiguring to gdm-service-type again (generation n+2).
>
> The problem was that the 'gdm' user id number (or group id number) was
> not the same in generations n and n+2, which prevented GDM from
> accessing the '/var/lib/gdm' directory.

When did that happen?

Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
ensures that /var/lib/gdm has proper ownership.

Thanks,
Ludo’.

bug#40652: #36924 way solves the problem for me

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]


Ludovic Courtès <ludo@gnu.org> skribis:

> Hi Guillaume,
>
> Guillaume Le Vaillant <glv@posteo.net> skribis:
>
>> I don't know if it's related, but recently I had GDM crashes at boot
>> after reconfiguring a system using gdm-service-type (generation n) to
>> make it use slim-service-type instead (generation n+1), and then
>> reconfiguring to gdm-service-type again (generation n+2).
>>
>> The problem was that the 'gdm' user id number (or group id number) was
>> not the same in generations n and n+2, which prevented GDM from
>> accessing the '/var/lib/gdm' directory.
>
> When did that happen?
>
> Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
> ensures that /var/lib/gdm has proper ownership.
>
> Thanks,
> Ludo’.

I think it was around 2 weeks ago.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

bug#40652: #36924 way solves the problem for me

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]


Guillaume Le Vaillant <glv@posteo.net> skribis:

> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> Hi Guillaume,
>>
>> Guillaume Le Vaillant <glv@posteo.net> skribis:
>>
>>> I don't know if it's related, but recently I had GDM crashes at boot
>>> after reconfiguring a system using gdm-service-type (generation n) to
>>> make it use slim-service-type instead (generation n+1), and then
>>> reconfiguring to gdm-service-type again (generation n+2).
>>>
>>> The problem was that the 'gdm' user id number (or group id number) was
>>> not the same in generations n and n+2, which prevented GDM from
>>> accessing the '/var/lib/gdm' directory.
>>
>> When did that happen?
>>
>> Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
>> ensures that /var/lib/gdm has proper ownership.
>>
>> Thanks,
>> Ludo’.
>
> I think it was around 2 weeks ago.

Concerning the service extensions of gdm-service-type, is it guaranteed
that %gdm-activation will be run after %gdm-accounts and not before?
If it's not the case it could explain the problem...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

bug#40652: #36924 way solves the problem for me

[Ludovic Courtès]

Guillaume Le Vaillant <glv@posteo.net> skribis:

> Guillaume Le Vaillant <glv@posteo.net> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> skribis:
>>
>>> Hi Guillaume,
>>>
>>> Guillaume Le Vaillant <glv@posteo.net> skribis:
>>>
>>>> I don't know if it's related, but recently I had GDM crashes at boot
>>>> after reconfiguring a system using gdm-service-type (generation n) to
>>>> make it use slim-service-type instead (generation n+1), and then
>>>> reconfiguring to gdm-service-type again (generation n+2).
>>>>
>>>> The problem was that the 'gdm' user id number (or group id number) was
>>>> not the same in generations n and n+2, which prevented GDM from
>>>> accessing the '/var/lib/gdm' directory.
>>>
>>> When did that happen?
>>>
>>> Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
>>> ensures that /var/lib/gdm has proper ownership.
>>>
>>> Thanks,
>>> Ludo’.
>>
>> I think it was around 2 weeks ago.
>
> Concerning the service extensions of gdm-service-type, is it guaranteed
> that %gdm-activation will be run after %gdm-accounts and not before?
> If it's not the case it could explain the problem...

‘%gdm-activation’ would throw an exception if the “gdm” user didn’t
exist, so apparently it’s run before the activation snippet of
‘account-service-type’ (the ordering guarantee is not explicit.)

Hmm I wonder what I’m missing then.  Would you like to try again?

Now, I think we should generalize this chown thing and apply it to all
the user accounts.  ‘user-homes’ would chown recursively if needed or
use the newfangled shiftfs, like systemd-homed does¹.

Thoughts?

Ludo’.

¹ https://systemd.io/HOME_DIRECTORY/

bug#40652: #36924 way solves the problem for me

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]


Ludovic Courtès <ludo@gnu.org> skribis:

> ‘%gdm-activation’ would throw an exception if the “gdm” user didn’t
> exist, so apparently it’s run before the activation snippet of
> ‘account-service-type’ (the ordering guarantee is not explicit.)
>
> Hmm I wonder what I’m missing then.  Would you like to try again?

I tried again and I wasn't able to reproduce the problem.
Maybe I did something weird with my config last time, but I can't
remember what it could have been...

> Now, I think we should generalize this chown thing and apply it to all
> the user accounts.  ‘user-homes’ would chown recursively if needed or
> use the newfangled shiftfs, like systemd-homed does¹.
>
> Thoughts?
> Ludo’.
>
> ¹ https://systemd.io/HOME_DIRECTORY/

A recursive chown for system accounts (with their home directory
somewhere in '/var') sounds like a good idea.

For user accounts (in '/home'), I guess it could be slightly annoying if
a user wants to set a specific group id to some of their files and if it
gets set back to the 'users' group at each system reconfiguration.
However it's probably not a very common use case, and if we only change
the files' uid, they could end up with an invalid gid anyway.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

bug#40652: #36924 way solves the problem for me

[Ludovic Courtès]

Hi,

Guillaume Le Vaillant <glv@posteo.net> skribis:

> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> ‘%gdm-activation’ would throw an exception if the “gdm” user didn’t
>> exist, so apparently it’s run before the activation snippet of
>> ‘account-service-type’ (the ordering guarantee is not explicit.)
>>
>> Hmm I wonder what I’m missing then.  Would you like to try again?
>
> I tried again and I wasn't able to reproduce the problem.
> Maybe I did something weird with my config last time, but I can't
> remember what it could have been...

OK.

>> Now, I think we should generalize this chown thing and apply it to all
>> the user accounts.  ‘user-homes’ would chown recursively if needed or
>> use the newfangled shiftfs, like systemd-homed does¹.
>>
>> Thoughts?
>> Ludo’.
>>
>> ¹ https://systemd.io/HOME_DIRECTORY/
>
> A recursive chown for system accounts (with their home directory
> somewhere in '/var') sounds like a good idea.
>
> For user accounts (in '/home'), I guess it could be slightly annoying if
> a user wants to set a specific group id to some of their files and if it
> gets set back to the 'users' group at each system reconfiguration.
> However it's probably not a very common use case, and if we only change
> the files' uid, they could end up with an invalid gid anyway.

Right.  The recursive chown would only happen if the home directory
itself has the wrong UID though, so that would still let you fiddle with
ownership of the files within it.  Worth trying!

Thanks,
Ludo’.

bug#40652: GDM does not starts after April 10 system reconfigure

[Maxim Cournoyer]

Hello,

R Veera Kumar <vkor@vkten.in> writes:

> The solution in bug #36924 solved the problem in my system.
>
> Remove /var/lib/gdm and make a empty one instead.

Thanks for letting us know.

Closing since #36924 is still open.

Thanks,

Maxim

bug#40652: GDM does not starts after April 10 system reconfigure

[sirgazil via Bug reports for GNU Guix]

Yes, Rene, that worked.

I deleted "/var/lib/gdm" and also ".local/share" and ".cache", which were 4.7 GiB and 2.9 GiB respectively.

Reading bug #36924 now I remember I've been through this before.