Hello,
I reinstalled that package.
# aptitude reinstall libpam-systemd
[…]
Preparing to unpack .../libpam-systemd_204-10_amd64.deb ...
Unpacking libpam-systemd:amd64 (204-10) over (204-10) ...
Processing triggers for man-db (2.6.7.1-1) ...
Paramétrage de libpam-systemd:amd64 (204-10) ...
I’ll try to upgrade again gdm, and test it in a minute or two.
# aptitude versions gdm3 libgdm1
Paquet gdm3 :
i A 3.8.4-6 testing 500
p A 3.8.4-7 unstable 500
Paquet gir1.2-gdm3 :
i A 3.8.4-6 testing 500
p A 3.8.4-7 unstable 500
Paquet libgdm1 :
i A 3.8.4-6 testing 500
p A 3.8.4-7 unstable 500
Otherwise, the gdm user has no shell. (seems sensible, right?)
# cat /etc/passwd | grep gdm
Debian-gdm:x:113:119:Gnome Display Manager:/var/lib/gdm3:/bin/false
By the way, my user uses the /bin/zsh shell (not fancy to me :-).
Here are various configuration files, which might be relevant?
$ cat /etc/pam.d/common-session
#
# /etc/pam.d/common-session - session-related modules common to all services
#
# […]
# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session optional pam_systemd.so
session optional pam_ck_connector.so nox11
# end of pam-auth-update config
$ cat /etc/pam.d/gdm3
#%PAM-1.0
auth requisite pam_nologin.so
auth required pam_succeed_if.so user != root quiet_success
@include common-auth
auth optional pam_gnome_keyring.so
@include common-account
# SELinux needs to be the first session rule. This ensures that any
# lingering context has been cleared. Without out this it is possible
# that a module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad]
pam_selinux.so close
session required pam_limits.so
session required pam_env.so readenv=1
session required pam_env.so readenv=1 envfile=/etc/default/locale
session required pam_loginuid.so
@include common-session
# SELinux needs to intervene at login time to ensure that the process
# starts in the proper default security context. Only sessions which are
# intended to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad]
pam_selinux.so open
session optional pam_gnome_keyring.so auto_start
@include common-password
Thank you,
Benjamin.
Le 08/05/2014 09:11, Laurent Bigonville a écrit :
> Le Thu, 8 May 2014 09:08:36 +0200,
> Laurent Bigonville <bi...@debian.org> a écrit :
>
>> Le Wed, 07 May 2014 17:33:01 +0200,
>> Benjamin Menant <benjamin.men...@gmail.com> a écrit :
>>
>>> Well, I am not sure… It’s more or less a default Jessie
>>> installation. I hope those following data will help. Please let me
>>> know.
>>>
>>>
>> [...]
>>
>> So apparently I see a session opened here so logind itself seems to
>> work as expected.
>>
>> But looking closer in the logs you posted, I see:
>>
>> gdm3][4091]: pam_systemd(gdm3:session): Failed to create session: No
>> such file or directory
>>
>> This is a bit puzzling me. Could you please try to reinstall the
>> libpam-systemd package maybe.
>>
>> Also in the logs I see the following warning/error:
>>
>> The value for the SHELL variable was not found the /etc/shells file
>>
>> Are you using some fancy shell for your user?
>
> Oh correction it seems to complain about gdm user shell:
>
> May 6 13:10:38 ****** pkexec[3298]: Debian-gdm: The value for the SHELL
> variable was not found the /etc/shells file [USER=root] [TTY=unknown]
> [CWD=/var/lib/gdm3]
> [COMMAND=/usr/lib/gnome-settings-daemon/gsd-backlight- helper
> --set-brightness 16]
>
signature.asc
Description: OpenPGP digital signature
