There is a regression introduced in gnome-base/gdm-3.4.1-r1 and not present in gnome-base/gdm-3.4.1, leading to inability to login via gdm, at all, with the correct username and password. Removing the pam_systemd line from /etc/pam.d/gdm-password fixes it for me, but I don't know why. I do use systemd. Also I wonder why pam_loginuid is not used. Reproducible: Always Steps to Reproduce: 1. Click your username in gdm 2. Enter the correct password Actual Results: gdm returns to the user selection screen, without any delay Expected Results: gdm should have started a gnome session or whatever the user selected aep-desktop ~ # emerge -pv gdm pambase These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-auth/pambase-20120417-r1 USE="cracklib gnome-keyring sha512 systemd -consolekit -debug -minimal -mktemp -pam_krb5 -pam_ssh -passwdqc (-selinux)" 0 kB [ebuild R ] gnome-base/gdm-3.4.1-r1 USE="fallback gnome-keyring gnome-shell introspection ipv6 ldap systemd tcpd xinerama xklavier -accessibility -audit -consolekit -debug -fprint -plymouth (-selinux) -smartcard -test" 0 kB Total: 2 packages (2 reinstalls), Size of downloads: 0 kB aep-desktop ~ # emerge --info Portage 2.1.11.16 (default/linux/x86/10.0/desktop/gnome, gcc-4.6.3, glibc-2.15-r2, 3.5.0-gentoo i686) ================================================================= System uname: Linux-3.5.0-gentoo-i686-Intel-R-_Core-TM-_i3_CPU_M_370_@_2.40GHz-with-gentoo-2.2 Timestamp of tree: Thu, 13 Sep 2012 03:15:01 +0000 app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.12 dev-lang/python: 2.7.3-r2, 3.2.3-r1 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.10.5 sys-apps/sandbox: 2.6 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.11.6, 1.12.3 sys-devel/binutils: 2.22.90 sys-devel/gcc: 4.5.4, 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.5 (virtual/os-headers) sys-libs/glibc: 2.15-r2 Repositories: gentoo x-portage renpy-games ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=core2 -pipe -fno-strict-aliasing -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=core2 -pipe -fno-strict-aliasing -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -march=i686 -pipe" FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch xattr" FFLAGS="-O2 -march=i686 -pipe" GENTOO_MIRRORS="http://mirror.yandex.ru/gentoo-distfiles http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="ru_RU.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/gentoo-renpy-games" SYNC="rsync://mirror.yandex.ru/gentoo-portage" USE="X a52 aac acl acpi alsa amr avahi bash-completion berkdb bluetooth bluray branding bzip2 cairo cdda cddb cdr cjk cli colord cracklib crypt cups cxx dbus djvu dri dts dvd dvdr eds emboss encode evo exif ffmpeg firefox flac fontconfig fortran gdbm gif gnome gnome-keyring gnome-online-accounts gphoto2 gstreamer gtk gtk3 iconv icu idn introspection ipv6 jack jpeg lcms ldap libnotify mad matroska mmx mmxext mng modules mp3 mp4 mpeg mudflap musepack nautilus ncurses networkmanager nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pppd pulseaudio qt3support readline scanner sdl session socialweb spell sse sse2 sse3 ssl ssse3 startup-notification svg systemd tcpd theora tiff truetype udev udisks unicode upnp upower usb v4l v4l2 vaapi vim-syntax vorbis wavpack webkit wxwidgets x264 x86 xattr xcb xface xinerama xml xv xvid zeitgeist zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" DRACUT_MODULES="crypt lvm systemd" DVB_CARDS="tda10046lifeview" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" QEMU_SOFTMMU_TARGETS="x86_64 arm cris i386 m68k microblaze mips mips64 mips64el mipsel ppc ppc64 ppcemb sh4 sh4eb sparc sparc64" QEMU_USER_TARGETS="alpha arm armeb cris i386 m68k microblaze mips mipsel ppc ppc64 ppc64abi32 sh4 sh4eb sparc sparc32plus sparc64 x86_64" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="gt68xx" USERLAND="GNU" VIDEO_CARDS="intel nouveau" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" USE_PYTHON="2.7 2.7-pypy-1.9 3.2" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
And for other systemd users, without the pam_systemd line, gnome-shell crashes immediately after login :(
Please attach the /var/log/gdm/:0-greeter.log and /var/log/gdm/:0-slave.log that are generated after a failed login with gdm-3.4.1-r1.
Created attachment 323880 [details] Greeter log
Created attachment 323882 [details] Slave log
Created attachment 323884 [details] tar.gz of all my pam files, just in case
There doesn't seem to be anything suspicious in the log. @systemd, any suggestions for what might be going wrong and how gdm should use pam_systemd?
@Patrakov your pam.d/gdm doesnt use provided pam.d/system-xxx For me kdm starting a kde session without consolekit works as follows: /etc/pam.d/kde --- #%PAM-1.0 auth include system-local-login account include system-local-login password include system-local-login session include system-local-login --- /etc/pam.d/system-local-login just redirects for now --- auth include system-login account include system-login password include system-login session include system-login --- /etc/pam.d/system-login --- auth required pam_shells.so auth required pam_nologin.so auth include system-auth account required pam_access.so account required pam_nologin.so account include system-auth password include system-auth session optional pam_loginuid.so session required pam_env.so session include system-auth -session optional pam_systemd.so --- The last one of mine is less than yours, I dont have gnome-keyring
@Patrakov, I just see you have additional cracklib enabled in /etc/pam.d/system-auth, mine is more simple: --- auth required pam_env.so auth required pam_unix.so try_first_pass likeauth nullok auth optional pam_permit.so account required pam_unix.so account optional pam_permit.so password required pam_unix.so try_first_pass nullok sha512 shadow password optional pam_permit.so session required pam_limits.so session required pam_env.so session optional pam_mktemp.so session required pam_unix.so session optional pam_permit.so --- I have additional pam_mktemp, which might be obsolete with systemd....
I've installed systemd on one of my machines and found a way to reproduce the problem. I believe the solution is to add pam_systemd to gdm-welcome. Please check whether the following fixes the gdm login problem (assuming you have pambase[systemd] and gdm[systemd]): /etc/pam.d/gdm-welcome : #%PAM-1.0 auth required pam_env.so -auth sufficient pam_ldap.so try_first_pass ignore_authinfo_unavail auth required pam_permit.so account required pam_nologin.so account include system-services password include system-services session optional pam_loginuid.so session optional pam_keyinit.so force revoke session include system-services -session optional pam_systemd.so /etc/pam.d/gdm-password : #%PAM-1.0 auth include system-local-login account include system-local-login password include system-local-login session include system-local-login
For gnome-overlay ~amd64 I can confirm that adding pam_systemd as optional to /etc/pam.d/gdm-launch-environment resolves the login issue. I have USE="systemd -consolekit" set globally and use the latest ebuilds from gnome overlay.
I had the same problem as described in this bug. I can confirm that adding pam_systemd.so to gdm-welcome AND removing it from gdm-password solved the problem for me. Somehow related to that, most of the pam_systemd.so lines in /etc/pam.d/gdm* configurations started with a '-' (minus) character e.g.: -session optional pam_systemd.so As I could not figure out, what's their role or if it's a bug, I removed them during debugging. It works for me without those '-' (minus) characters. Concerned files: /etc/pam.d/gdm /etc/pam.d/gdm-autologin /etc/pam.d/gdm-fingerprint /etc/pam.d/gdm-password /etc/pam.d/gdm-smartcard If I should open an extra bug for this issue, let me know, I'm happy to do so. If additional information is required, I'm happy to provide it.
(In reply to comment #11) > Somehow related to that, most of the pam_systemd.so lines in /etc/pam.d/gdm* > configurations started with a '-' (minus) character e.g.: > -session optional pam_systemd.so Reading again the pam-d man page I found the role of the '-' (minus) character. It's about logging. Sorry for the noise :-(
Adding "session optional pam_systemd.so" to gdm-welcome after pam_loginuid.so does not help here.
Alex, do you have kernel option CONFIG_AUDIT_LOGINUID_IMMUTABLE enabled? pam_loginuid.so is required by default and gdm will fail if the above kernel option is enabled. systemd is (I think) supposed to set the loginuid process attribute from a root user account thus avoiding issues with CONFIG_AUDIT_LOGINUID_IMMUTABLE being set. If CONFIG_AUDIT_LOGINUID_IMMUTABLE is enabled, make pam_loginuid.so optional in /etc/pam.d/* to get gdm working again.
Yes, I have that kernel option, and yes, adding "session optional pam_loginuid.so" as a first line of the "session" section in all gdm-related pam files helps. No need to comment out pam_systemd.so.
The fix is incomplete. While it allows me to login, it does not work the second time. I.e.: 1. Log in using the correct username and password => success 2. Log out => success 3. Click your username again => see that gdm doesn't even list session types anymore 4. Type your password => it does not let you in, returns to the screen where you can select a user name.
Same here. I found the reason is that some processes (most notably /usr/bin/pulseaudio) remain after logout and apparently keep the session alive, so that gdm doesn't start a new session. Killing these processes allows logging in again. Best regards, Bernd
(In reply to comment #17) > Same here. > I found the reason is that some processes (most notably /usr/bin/pulseaudio) > remain after logout and apparently keep the session alive, so that gdm > doesn't start a new session. Killing these processes allows logging in again. What versions of systemd do you have, and with what USE flags? Please check that pulseaudio and pambase were built with USE=systemd, and that you have CONFIG_CGROUPS=y in your kernel config.
(In reply to comment #18) > (In reply to comment #17) > > Same here. > > I found the reason is that some processes (most notably /usr/bin/pulseaudio) > > remain after logout and apparently keep the session alive, so that gdm > > doesn't start a new session. Killing these processes allows logging in again. > > What versions of systemd do you have, and with what USE flags? Please check > that pulseaudio and pambase were built with USE=systemd, emerge -pv systemd pulseaudio pambase These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-apps/systemd-189-r3 USE="acl lzma pam tcpd -audit -cryptsetup -gcrypt -qrcode (-selinux)" 0 kB [ebuild R ] media-sound/pulseaudio-2.1-r1 USE="X alsa asyncns caps dbus gdbm glib gnome gtk ipv6 jack libsamplerate orc ssl systemd tcpd udev webrtc-aec -avahi -bluetooth -doc -equalizer -lirc (-oss) -realtime (-system-wide) {-test} -xen" 0 kB [ebuild R ] sys-auth/pambase-20120417-r1 USE="consolekit cracklib gnome-keyring sha512 systemd -debug -minimal -mktemp -pam_krb5 -pam_ssh -passwdqc (-selinux)" 0 kB > and that you have > CONFIG_CGROUPS=y in your kernel config. CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_DEVICE is not set # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_RESOURCE_COUNTERS is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set CONFIG_RT_GROUP_SCHED=y CONFIG_BLK_CGROUP=y ... CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y CONFIG_AUDIT_LOGINUID_IMMUTABLE=y Regards, Bernd
I forgot that you also need to modify /usr/bin/gdm to replace: gdm-binary & With just: gdm-binary systemd already starts the gdm service asynchronously via gdm.service. If using pulseaudio you'll also need to edit /usr/bin/start-pulseaudio-x11 and comment out the following line: /usr/bin/pactl load-module module-x11-publish "display=$DISPLAY" > /dev/null When gdm first launches, pulseaudio is spawned and will write session IDs for the gdm user into the X root window properties. If you try to login with an actual user, pulseaudio will try to respawn under the real user account but will mistakenly try to use the session IDs obtained from the X root window -- the session IDs of the "gdm" user for which the real user does not have access to use.
One more comment I forgot -- systemd's graphical.target will try to launch display-manager.service that doesn't exist in Gentoo. The correct fix is probably to implement eselect-display-manager which switches symlinks between a GDM display-manager.service, KDE display-manager.service, etc as the user selects. A quick hack is to edit /usr/lib/systemd/system/graphical.target and change display-manager.service to gdm.service.
(In reply to comment #21) > One more comment I forgot -- > > systemd's graphical.target will try to launch display-manager.service that > doesn't exist in Gentoo. > > The correct fix is probably to implement eselect-display-manager which > switches symlinks between a GDM display-manager.service, KDE > display-manager.service, etc as the user selects. > > A quick hack is to edit /usr/lib/systemd/system/graphical.target and change > display-manager.service to gdm.service. Please stop over-engineering things. The correct way is to have: [Install] Alias=display-manager.service and then 'systemctl enable gdm.service' will create an appropriate symlink. Not that they are just stupid and inventing the same thing as graphical.target did...
Pulseaudio maintainers, please take a look at comment 17 and comment 20. What changes should gdm and pulseaudio add to fix the problem?
Please test whether gdm-3.4.1-r2 fixes the login issues
(In reply to comment #24) > Please test whether gdm-3.4.1-r2 fixes the login issues Works for me.
Works for me during the first login, doesn't work for the second.
(In reply to comment #24) > Please test whether gdm-3.4.1-r2 fixes the login issues For me, with systemd-192/udev-192 now, pulseaudio-2.1-r1 still remains active after logout but now at least disappears after 20s, as advertised. So if I wait a while after logging out, I can log in again. Note that strangely this behavior is somewhat instable, since I sometimes managed to log in directly after logging out. Another rather strange observation is this: When I used gnome-session-properties to disable autostart of gnome-keyring-secrets, a process "/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets" remained running after logout and likewise impeded a new login. While pulseaudio, as described, disappeared after 20s together with its gconf-helper, this process remained running. So there's a difference between autostarted and started-on-demand processes which shouldn't be there. [pulseaudio.desktop is not disabled BTW] Re. Comment #20 (David Hicks): /usr/bin/gdm is a symlink to /usr/sbin/gdm-binary here. Also whether or not module-x11-publish is loaded in /usr/bin/start-pulseaudio-x11 did not make a difference. Anyway, in a more-or-lessish way gdm-3.4.1-r2 works for me too. Thanks and regards, Bernd
I must add that, for me, not only pulseaudio lingers after user logout, but also gconf-helper.
Also I will consider this bug only hidden, not fixed, if pulseaudio is modified to stop lingering. It is a bug in GDM that it allows one misbehaving process in the previous session (today pulseaudio, tomorrow, let's say, flash-plugin) to subvert further logins.
I have created bug 436506 to track the "pulseaudio lingers after logout" issue. Let's use bug 435042 (i.e. this bug) for the issue that a lingering process (not necessarily pulseaudio) can subvert further logins via gdm.
As a sidenote, the pam.d files installed by gdm-3.4.1-r2 prevent sys-libs/pam-1.1.6 from being (r)emerged: * Your current setup is using one or more of the following modules, * that are not built or supported anymore: * pam_pwdb, pam_console * If you are in real need for these modules, please contact the maintainers * of PAM through http://bugs.gentoo.org/ providing information about its * use cases. * Please also make sure to read the PAM Upgrade guide at the following URL: * http://www.gentoo.org/proj/en/base/pam/upgrade-0.99.xml * ERROR: sys-libs/pam-1.1.6 failed (preinst phase): * deprecated PAM modules still used * * Call stack: * ebuild.sh, line 89: Called pkg_preinst * environment, line 3303: Called die * The specific snippet of code: * check_old_modules || die "deprecated PAM modules still used" # grep pam_pwdb /etc/pam.d/* # grep pam_console /etc/pam.d/* /etc/pam.d/gdm:session optional pam_console.so # equery belongs /etc/pam.d/gdm * Searching for /etc/pam.d/gdm ... gnome-base/gdm-3.4.1-r2 (/etc/pam.d/gdm) So I think the pam_console line should be eradicated.
(In reply to comment #31) You are right; fixed in 3.4.1-r3. >*gdm-3.4.1-r3 (29 Sep 2012) > > 29 Sep 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > -gdm-3.4.1-r2.ebuild, +gdm-3.4.1-r3.ebuild: > Do not install old /etc/pam.d/gdm file, it blocks sys-libs/pam from emerging > (bug #435042, thanks to Martin Wegner).
Adjusting severty, systemd isn't really a recommended option for now and there is no point in having this more critical than critical stuff.
I cannot call this a responsible maintainership of the involved packages. By this time, I'd expect from the real maintainer: 1) Finding the guilty party among gdm, systemd, pam and possibly other packages. 2) Forwarding the report to the correct upstream (or, failing (1), to at least _some_ upstream). 3) Putting the upstream bug/discussion URL into the URL field. However, since you are not going to do this due to more critical stuff, please at least mask the guilty USE flags so that other users don't step on this still-unfixed bug. Additional information that can help: if I deliberately introduce a lingering process (e.g. tmux) into the session, then systemd-cgls (from root login via getty) shows that the cgroup still exists, and loginctl shows that the corresponding session is in the "closing" state.
Please try with gdm-3.6.
(In reply to comment #35) > Please try with gdm-3.6. Here, gnome-base/gdm-3.6.2 lets me login whether or not pulseaudio and its gconf helper are running. So it appears to work correctly now.
ok, I'll close it as fixed then. Thanks for the update.
Fixed indeed.
