I could not reproduce this problem with 3.8.0 after downgrading and it started after today's upgrade - the gdm-slave fails with: GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed There is no possibility of logging in to system (other then tty). I have the core file but unfortunatly I have no debug information (overwritten by the downgrade).
1. Which versions of gnome-shell, dbus, pam and accountsservice do you have? 2. Do you get a black screen or can you see the login dialog? 3. (Only if you can see the login dialog) Can you interact with the login dialog? 4. (Only if you can interact with the login dialog) Does it bail out on login? 5. Please attach relevant logs: dmesg, /var/log/messages and /var/log/gdm/* 6. Since gdm does not take long to compile, please consider obtaining debug info. Thank you in advance.
Are you running systemd?
I think TomWij was suffering a similar problem some days ago. Also review: https://bbs.archlinux.org/viewtopic.php?pid=1198808 https://bugzilla.redhat.com/show_bug.cgi?id=873082 https://bugs.freedesktop.org/show_bug.cgi?id=57343 But I am currently running it without any problems with systemd :|
(In reply to Tom Wijsman (TomWij) from comment #1) > 1. Which versions of gnome-shell, dbus, pam and accountsservice do you have? gnome-shell: 3.8.3-r1 dbus: 1.6.12 pam: 1.1.6-r4 accountsservice: 0.6.30 > 2. Do you get a black screen or can you see the login dialog? No the slave is failing right at the beginning. > 3. (Only if you can see the login dialog) Can you interact with the login > dialog? > 4. (Only if you can interact with the login dialog) Does it bail out on > login? > 5. Please attach relevant logs: dmesg, /var/log/messages and /var/log/gdm/* Relevant part from logind (full is prohibitively long): Jul 14 22:26:22 localhost kernel: ehci-pci 0000:00:1d.0: power state changed by ACPI to D3cold Jul 14 22:26:23 localhost gdm[11439]: Failed to give slave programs access to the display. Trying to proceed. Jul 14 22:26:23 localhost gdm-launch-environment][11463]: pam_systemd(gdm-launch-environment:session): Unknown parameter 'kill-session-processes=1', ignoring Jul 14 22:26:23 localhost systemd-logind[2546]: Assertion 's->user->slice' failed at /var/tmp/portage/sys-apps/systemd-205/work/systemd-205/src/login/logind-session.c:463, function session_start_scope(). Aborting. Jul 14 22:26:23 localhost abrt[11466]: File '/usr/lib64/systemd/systemd-logind' seems to be deleted Jul 14 22:26:23 localhost abrt[11466]: Can't open file '/etc/system-release': No such file or directory Jul 14 22:26:23 localhost abrt[11466]: Saved core dump of pid 2546 (/usr/lib64/systemd/systemd-logind) to /var/spool/abrt/ccpp-2013-07-14-22:26:23-2546 (1110016 bytes) Jul 14 22:26:23 localhost abrtd[2540]: Directory 'ccpp-2013-07-14-22:26:23-2546' creation detected Jul 14 22:26:23 localhost abrtd[2540]: Lock file '/var/spool/abrt/ccpp-2013-07-13-22:04:44-2990/.lock' is locked by process 11466 Jul 14 22:26:23 localhost gdm-launch-environment][11463]: pam_systemd(gdm-launch-environment:session): Failed to create session: Message did not receive a reply (timeout by message bus) Jul 14 22:26:23 localhost systemd[1]: systemd-logind.service: main process exited, code=dumped, status=6/ABRT Jul 14 22:26:23 localhost systemd[1]: Unit systemd-logind.service entered failed state. Jul 14 22:26:23 localhost systemd[1]: systemd-logind.service holdoff time over, scheduling restart. Jul 14 22:26:23 localhost systemd[1]: Stopping Login Service... -- Jul 14 22:26:23 localhost systemd[1]: Started User Manager for 0. Jul 14 22:26:23 localhost systemd[11471]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted Jul 14 22:26:23 localhost systemd[1]: Started User Manager for 106. Jul 14 22:26:23 localhost systemd-logind[11468]: Failed to start session scope: Unit session-4.scope already exists. org.freedesktop.systemd1.UnitExists Jul 14 22:26:23 localhost systemd-logind[11468]: New session 4 of user gdm. Jul 14 22:26:23 localhost systemd-logind[11468]: Linked /tmp/.X11-unix/X0 to /run/user/106/X11-display. Jul 14 22:26:24 localhost abrtd[2540]: Generating backtrace Jul 14 22:26:25 localhost abrtd[2540]: New problem directory /var/spool/abrt/ccpp-2013-07-14-22:26:23-2546, processing Jul 14 22:26:25 localhost abrtd[2540]: cat: package: No such file or directory -- Jul 14 22:26:38 localhost systemd[1]: Started Session 7 of user root. Jul 14 22:26:38 localhost systemd[1]: Started User Manager for 0. Jul 14 22:26:38 localhost login[11505]: ROOT LOGIN on '/dev/tty1' Jul 14 22:27:04 localhost systemd[1]: Stopping GNOME Display Manager... Jul 14 22:27:04 localhost gdm[11439]: GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed Jul 14 22:27:04 localhost gdm[11439]: GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed (...) Jul 14 22:27:05 localhost gdm[11439]: GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed Jul 14 22:27:05 localhost gdm[11439]: GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed Jul 14 22:27:05 localhost kernel: gdm-simple-slav[11442]: segfault at 7fff6894af08 ip 00007fb8900822c7 sp 00007fff6894ae00 error 6 in libc-2.17.so[7fb890039000+1a2000] Jul 14 22:27:05 localhost gdm[11439]: GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed (...) Jul 14 22:27:05 localhost gdm[11439]: GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed Jul 14 22:27:05 localhost abrt[11777]: Can't open file '/etc/system-release': No such file or directory Jul 14 22:27:05 localhost gdm[11439]: GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed (...) Jul 14 22:27:05 localhost gdm[11439]: GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed Jul 14 22:27:05 localhost abrt[11777]: Saved core dump of pid 11442 (/usr/libexec/gdm-simple-slave) to /var/spool/abrt/ccpp-2013-07-14-22:27:05-11442 (34893824 bytes) Jul 14 22:27:05 localhost abrtd[2540]: Directory 'ccpp-2013-07-14-22:27:05-11442' creation detected Jul 14 22:27:05 localhost abrt[11777]: Lock file '/var/spool/abrt/ccpp-2013-07-13-22:04:44-2990/.lock' is locked by process 2540 Jul 14 22:27:05 localhost abrtd[2540]: Generating backtrace Jul 14 22:27:06 localhost systemd[1]: Stopped GNOME Display Manager. > 6. Since gdm does not take long to compile, please consider obtaining debug > info. > Right now I need to do something but I will send the stacktrace tomorrow. (In reply to Pacho Ramos from comment #2) > Are you running systemd? Yes (In reply to Pacho Ramos from comment #3) > I think TomWij was suffering a similar problem some days ago. Also review: > https://bbs.archlinux.org/viewtopic.php?pid=1198808 > https://bugzilla.redhat.com/show_bug.cgi?id=873082 > https://bugs.freedesktop.org/show_bug.cgi?id=57343 > > But I am currently running it without any problems with systemd :| Last one seems to be different bug (and I have 64 bit system). The other too looks like the same bug.
Created attachment 353292 [details] :0.log I attach relevant files from /var/log/gdm (i.e. from correct run).
Created attachment 353294 [details] /var/log/gdm/:0-slave.log
Created attachment 353296 [details] :0-greeter.log Strangely most of errors are in successful run as well.
logind looks to be failing in your system
Also post emerge --info please
Portage 2.2.0_alpha188 (default/linux/amd64/13.0/desktop/gnome, gcc-4.8.1, glibc-2.17, 3.9.5-pf x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.9.5-pf-x86_64-Intel-R-_Core-TM-_i7-3820QM_CPU_@_2.70GHz-with-gentoo-2.2 KiB Mem: 16069604 total, 9916220 free KiB Swap: 20971484 total, 20971484 free Timestamp of tree: Sun, 14 Jul 2013 19:15:01 +0000 ld GNU ld (Linux/GNU Binutils) 2.23.52.0.2.20130423 app-shells/bash: 4.2_p45 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.5-r1, 3.2.5-r1, 3.3.2-r1 dev-util/cmake: 2.8.11.1 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6, 1.14 sys-devel/binutils: 2.23.52.0.2 sys-devel/gcc: 4.6.4, 4.8.1 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r5::gnome sys-kernel/linux-headers: 3.9 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo crossdev x11 gentoo-haskell vala science mozilla steam-overlay dotnet bumblebee gnome local ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe -ggdb -Wa,--compress-debug-sections" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.0/conf" 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/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=native -pipe -ggdb -Wa,--compress-debug-sections" DISTDIR="/var/tmp/distfiles" EMERGE_DEFAULT_OPTS="-j8 --load-average=7" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs clean-logs compress-build-logs compressdebug config-protect-if-modified distlocks ebuild-locks fail-clean fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms split-elog splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ ftp://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://ftp.heanet.ie/pub/gentoo/ ftp://ftp.heanet.ie/pub/gentoo/" LANG="en_GB.UTF-8" LC_ALL="en_GB.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--add-needed -Wl,--hash-style=both -Wl,--sort-common -Wl,--no-keep-memory" MAKEOPTS="-j8 -l7" 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-crossdev /var/lib/layman/x11 /var/lib/layman/haskell /var/lib/layman/vala /var/lib/layman/science /var/lib/layman/mozilla /var/lib/layman/steam /var/lib/layman/dotnet /var/lib/layman/bumblebee /var/lib/layman/gnome /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 avx berkdb bluetooth branding bzip2 bzr c++0x cairo caps cdda cdr cli clutter colord cracklib crypt cryptsetup cups cxx dbus dconf debugger device-mapper dri dts dvd dvdr eds emacs emboss encode evo exif fam ffmpeg firefox firewalld flac flash fontconfig fortran fprint fuse g3dvl gbm gdbm gdm gif git gmp gnome gnome-keyring gnome-online-accounts gnuplot gnutls google gpm grilo gsettings gstreamer gtk gtk3 gtkstyle gui iconv inotify introspection iproute2 ipsec ipv6 ipython irc ithreads jabber jemalloc jpeg kerberos laptop latex lcms ldap libkms libnotify libproxy libsecret llvm lvm lzma mad map mercurial mmx mng modules mp3 mp4 mpeg mudflap multilib nautilus ncurses networking networkmanager nls nptl nsplugin ogg opencl opengl openmp oss pam pango parted pch pcre pdf perl pkcs11 plotutils png policykit ppds profiler pulseaudio python python3 qemu qt4 readline realtime rss samba sdl session sna socialweb spell spice sqlite sse sse2 sse4_1 sse4_2 ssl ssse3 startup-notification steamruntime subversion svg symlink systemd tcpd telepathy theora threads tiff tracker truetype udev udisks unicode upnp upower usb v4l vaapi vala vdpau virt-network virtfs vorbis vpx webkit wxwidgets x264 xattr xcb xcomposite xinerama xml xrandr xv xvid zeitgeist zlib zsh-completion" ABI_X86="32 64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd 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 author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" DRACUT_MODULES="caps crypt lvm systemd" 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" GRUB_PLATFORMS="pc efi-64" INPUT_DEVICES="evdev synaptics mouse mutouch" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en pl en_GB" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-4" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2 python3_3 jython2_5" QEMU_SOFTMMU_TARGETS="arm x86_64 i386" QEMU_USER_TARGETS="arm x86_64 i386" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="intel nvidia" 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 3.3" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= gnome-base/gdm-3.8.0 was built with the following: USE="fallback fprint gnome-shell introspection ipv6 ldap systemd tcpd xinerama -accessibility -audit -consolekit -debug -plymouth (-selinux) -smartcard -test"
> Jul 14 22:26:23 localhost gdm[11439]: Failed to give slave programs access > to the display. Trying to proceed. ^ Bummer 1, I bisected this one; offending commit: https://mail.gnome.org/archives/commits-list/2012-October/msg00304.html Commit that points out above commits but doesn't fix it for me: https://mail.gnome.org/archives/commits-list/2012-October/msg04604.html > Jul 14 22:26:23 localhost gdm-launch-environment][11463]: > pam_systemd(gdm-launch-environment:session): Unknown parameter > 'kill-session-processes=1', ignoring ^ Bummer 2, misconfiguration somewhere; though this might not be important. > Jul 14 22:26:23 localhost systemd-logind[2546]: Assertion 's->user->slice' > failed at > /var/tmp/portage/sys-apps/systemd-205/work/systemd-205/src/login/logind- > session.c:463, function session_start_scope(). Aborting. ^ Bummer 3, assertion failing sounds bad; especially since it aborts. > Jul 14 22:26:23 localhost abrt[11466]: File > '/usr/lib64/systemd/systemd-logind' seems to be deleted ^ Bummer 4, present on my system; can you check if the file is present for you? Try emerging systemd again to restore it; if it still gives that error then `emerge app-portage/portage-utils` and attach `qcheck sys-apps/systemd` > Jul 14 22:26:23 localhost abrt[11466]: Saved core dump of pid 2546 > (/usr/lib64/systemd/systemd-logind) to > /var/spool/abrt/ccpp-2013-07-14-22:26:23-2546 (1110016 bytes) ^ Bummer 5, heh, it core dumps for that process; so the file is present?! > Jul 14 22:26:23 localhost gdm-launch-environment][11463]: > pam_systemd(gdm-launch-environment:session): Failed to create session: > Message did not receive a reply (timeout by message bus) ^ Bummer 6, this is a consequence of bummer 1 above; a dbus related timeout. > Jul 14 22:26:23 localhost systemd[11471]: Failed at step PAM spawning > /usr/lib/systemd/systemd: Operation not permitted ^ Bummer 7, pam configuration issue, I think this one needs "session optional pam_systemd.so" at the bottom of /etc/pam.d/system-auth (In reply to Maciej Piechotka from comment #7) > Created attachment 353296 [details] > :0-greeter.log > > Strangely most of errors are in successful run as well. Do you see "failed to create drawable" in a succesful run? This is the error I expect it would throw for me; but it doesn't, screen stays black but shows my mouse which I can move. Both this for gdm or when I run gnome-shell separately; so, I would expect to get this very same error. :/ Anyhow, unless it is just the systemd-logind file missing; our issue is similar.
Ah, an idea, can you please attach the same bit from journalctl for your working case with 3.8.0? We could compare which errors you get there and which you don't.
(In reply to Tom Wijsman (TomWij) from comment #11) > > Jul 14 22:26:23 localhost gdm[11439]: Failed to give slave programs access > > to the display. Trying to proceed. > > ^ Bummer 1, I bisected this one; offending commit: > > https://mail.gnome.org/archives/commits-list/2012-October/msg00304.html > > Commit that points out above commits but doesn't fix it for me: > > https://mail.gnome.org/archives/commits-list/2012-October/msg04604.html > Nice to see you found the culprit, is upstream aware of the issue? > > Jul 14 22:26:23 localhost gdm-launch-environment][11463]: > > pam_systemd(gdm-launch-environment:session): Unknown parameter > > 'kill-session-processes=1', ignoring > > ^ Bummer 2, misconfiguration somewhere; though this might not be important. > Probably: http://wiki.gentoo.org/wiki/Systemd#systemd-logind_.26_pam_systemd is obsolete (I didn't add that parameter and all looks to work ok)
(In reply to Pacho Ramos from comment #13) > (In reply to Tom Wijsman (TomWij) from comment #11) > > > Jul 14 22:26:23 localhost gdm[11439]: Failed to give slave programs access > > > to the display. Trying to proceed. > > > > ^ Bummer 1, I bisected this one; offending commit: > > > > https://mail.gnome.org/archives/commits-list/2012-October/msg00304.html > > > > Commit that points out above commits but doesn't fix it for me: > > > > https://mail.gnome.org/archives/commits-list/2012-October/msg04604.html > > > > Nice to see you found the culprit, is upstream aware of the issue? Sorry, I don't have time to follow up with upstream until August. Anyhow, I've digged into that second link and saw a mention of a gdm-initial-setup user; so, I've added that user an ended up following these instructions. https://github.com/GNOME/gnome-initial-setup/blob/master/gnome-initial-setup/README The gdm-setup.session file I deduced from the following commit I found: https://mail.gnome.org/archives/commits-list/2012-April/msg04517.html After that, I no longer get the above error; which is progress! Therefore I suggest OP to try the above as well. Sadly, my Gnome is so broken that I am experiencing a black screen; but I think, I got a step further. After giving 777 permissions and gdm:gdm to /run/user/* a few times (you said something about checking those permissions, consider this a reminder; because they still are improper), runnning `gdm` and looking into `journalctl -r` a few times I saw the following error pop up: (gnome-settings-daemon:5019): GnomeDesktop-CRITICAL **: gnome_rr_output_info_get_geometry: assertion `GNOME_IS_RR_OUTPUT_INFO (self)' failed Interesting! It's not gnome-shell, not gdm; but gnome-settings-daemon that's failing now, and the crucial part here is "gnome_rr_output_info_get_geometry". So, I fired up gdb on gnome-settings, set a breakbpoint on gnome_rr_output_info_get_geometry and give it the same parameter to run with; lo and behold, a nice stack trace right before the error: Breakpoint 1, 0x00000039eb620910 in gnome_rr_output_info_get_geometry () from /usr/lib64/libgnome-desktop-3.so.7 (gdb) bt #0 0x00000039eb620910 in gnome_rr_output_info_get_geometry () from /usr/lib64/libgnome-desktop-3.so.7 #1 0x00007ffff4332c89 in () from /usr/lib64/gnome-settings-daemon-3.0/libxrandr.so #2 0x00000030c8039fe1 in ?? () from /lib64/libc.so.6 #3 0x00000030c803a28c in qsort_r () from /lib64/libc.so.6 #4 0x00007ffff4332d6f in trim_rightmost_outputs_that_dont_fit_in_framebuffer () from /usr/lib64/gnome-settings-daemon-3.0/libxrandr.so #5 0x00007ffff43344ec in make_xinerama_setup () from /usr/lib64/gnome-settings-daemon-3.0/libxrandr.so #6 0x00007ffff4335931 in gsd_xrandr_manager_start () from /usr/lib64/gnome-settings-daemon-3.0/libxrandr.so #7 0x00007ffff43326c3 in impl_activate () from /usr/lib64/gnome-settings-daemon-3.0/libxrandr.so #8 0x0000000000405ca0 in gnome_settings_plugin_info_activate () #9 0x0000000000404c05 in maybe_activate_plugin () #10 0x0000003fc726794d in g_slist_foreach () from /usr/lib64/libglib-2.0.so.0 #11 0x0000000000404f42 in gnome_settings_manager_start () #12 0x000000000040470f in name_acquired_handler () #13 0x00000031e92cd7ae in do_call () from /usr/lib64/libgio-2.0.so.0 #14 0x00000031e92cd9e0 in request_name_cb () from /usr/lib64/libgio-2.0.so.0 #15 0x00000031e9274587 in g_simple_async_result_complete () from /usr/lib64/libgio-2.0.so.0 #16 0x00000031e92c5882 in g_dbus_connection_call_done () from /usr/lib64/libgio-2.0.so.0 #17 0x00000031e9274587 in g_simple_async_result_complete () from /usr/lib64/libgio-2.0.so.0 #18 0x00000031e9274689 in complete_in_idle_cb () from /usr/lib64/libgio-2.0.so.0 #19 0x0000003fc724b5e5 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #20 0x0000003fc724b928 in g_main_context_iterate.isra.22 () from /usr/lib64/libglib-2.0.so.0 #21 0x0000003fc724bd9a in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #22 0x00000039e83a006d in gtk_main () from /usr/lib64/libgtk-3.so.0 #23 0x0000000000403f13 in main () (gdb) cont Continuing. (gnome-settings-daemon:5794): GnomeDesktop-CRITICAL **: gnome_rr_output_info_get_geometry: assertion `GNOME_IS_RR_OUTPUT_INFO (self)' failed The interesting part here is that it is compare_output_positions in xrandr in make_xinerama_setup; so, the problem in my case lies with xinerama perhaps. Looking at `euse -I xinerama` the relevent packages that have an USE flag are gdm and gtk+; I do see a mention of gtk+ in above backtrace but it's not near the actual failing code, which makes me a bit doubtful if I can disable Xinerama here. Looking at `equery d x11-libs/libXinerama` and `equery d x11-proto/xineramaproto` I do not see a direct dependency from anything else in the above backtrace though; at best, I learn that mutter depends on it as well, but that's probably not relevant. Removing libXinerama seems a bit tricky as some applications I use depend on them, although I could attempt to sacrifice them for a moment; but I'll try to at least disable the xinerama USE flag and test it that way to see if there is an improvement. So, maybe there's something wrong with my xrandr causing xinerama to fail? Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 LVDS-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 382mm x 215mm 1920x1080 60.0*+ 60.0 1680x1050 60.0 1400x1050 60.0 1280x1024 59.9 1280x960 59.9 1152x864 60.0 1024x768 59.9 800x600 59.9 640x480 59.4 720x400 59.6 640x400 60.0 640x350 59.8 HDMI-1 disconnected (normal left inverted right x axis y axis) DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 382mm x 215mm 1920x1080 60.0*+ LVDS is internal laptop display, DVI is a shared port (between LVDS and external DVI connector), HDMI is my external HDMI connector, there's also a DVI connector on the side but there's nothing attached. Maybe Xinerama or Gnome doesn't like the shared port concept here; in fact, Nouveau doesn't like it either so I wouldn't be surprised to see it fail in other places as well. Hopefully disabling the USE flag serves as a temporary solution; if not, I guess we'll have to go through a lot more debugging. Or well, maybe slaves still don't get access to the display and it now silently fails...
(Accidentally cut the compare_output_positions function in above backtrace at #1)
(In reply to Tom Wijsman (TomWij) from comment #12) > Ah, an idea, can you please attach the same bit from journalctl for your > working case with 3.8.0? We could compare which errors you get there and > which you don't. Something like: Jul 15 11:57:29 localhost NetworkManager[2594]: <info> (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] Jul 15 11:57:29 localhost NetworkManager[2594]: <info> (wlan0): bringing up device. Jul 15 11:57:29 localhost kernel: iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S Jul 15 11:57:29 localhost kernel: iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1 Jul 15 11:57:29 localhost gdm[2541]: Failed to give slave programs access to the display. Trying to proceed. Jul 15 11:57:30 localhost gdm-launch-environment][2829]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0) Jul 15 11:57:30 localhost gdm-launch-environment][2829]: pam_systemd(gdm-launch-environment:session): Unknown parameter 'controllers=cpu,blkio,bfqio', ignoring Jul 15 11:57:30 localhost systemd[1]: Starting user-106.slice. Jul 15 11:57:30 localhost systemd[1]: Created slice user-106.slice. Jul 15 11:57:30 localhost systemd[1]: Starting User Manager for 106... Jul 15 11:57:30 localhost systemd[1]: Starting Session 2 of user gdm. Jul 15 11:57:30 localhost systemd-logind[2519]: New session 2 of user gdm. Jul 15 11:57:30 localhost systemd-logind[2519]: Linked /tmp/.X11-unix/X0 to /run/user/106/X11-display. Jul 15 11:57:30 localhost systemd[1]: Started Session 2 of user gdm. Jul 15 11:57:30 localhost systemd[2984]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted Jul 15 11:57:30 localhost systemd[1]: Started User Manager for 106. Jul 15 11:57:31 localhost /usr/bin/dbus-launch[2991]: gnome-session[2991]: WARNING: Could not parse desktop file orca-autostart.desktop or it references a not found TryExec binary Jul 15 11:57:31 localhost gnome-session[2991]: WARNING: Could not parse desktop file orca-autostart.desktop or it references a not found TryExec binary Jul 15 11:57:32 localhost gnome-session[2991]: Entering running state Jul 15 11:57:32 localhost dbus-daemon[2521]: dbus[2521]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service' Jul 15 11:57:32 localhost dbus[2521]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service' Jul 15 11:57:32 localhost systemd[1]: Starting Manage, Install and Generate Color Profiles... Jul 15 11:57:32 localhost pulseaudio[3053]: [pulseaudio] authkey.c: Failed to open cookie file '/var/lib/gdm/.config/pulse/cookie': No such file or directory Jul 15 11:57:32 localhost pulseaudio[3053]: [pulseaudio] authkey.c: Failed to load authorization key '/var/lib/gdm/.config/pulse/cookie': No such file or directory Jul 15 11:57:32 localhost dbus-daemon[2521]: dbus[2521]: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' Jul 15 11:57:32 localhost dbus[2521]: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' Jul 15 11:57:32 localhost systemd[1]: [/usr/lib64/systemd/system/rtkit-daemon.service:27] Unknown lvalue 'ControlGroup' in section 'Service' Jul 15 11:57:32 localhost systemd[1]: Starting RealtimeKit Scheduling Policy Service... Jul 15 11:57:33 localhost colord[3057]: Profile added: icc-bc2d6f78dfa777ece4bda1ecabceefc6 Jul 15 11:57:33 localhost colord[3057]: Profile added: icc-b34df44a6b24c5f30a494ced7d84a8af Jul 15 11:57:33 localhost colord[3057]: Profile added: icc-5ed408334b2a73010c15d35d32b64f85 Jul 15 11:57:33 localhost colord[3057]: Device added: sysfs-Chicony_Electronics_Co.__Ltd.-Integrated_Camera Jul 15 11:57:33 localhost pulseaudio[3068]: [pulseaudio] authkey.c: Failed to open cookie file '/var/lib/gdm/.config/pulse/cookie': No such file or directory Jul 15 11:57:33 localhost pulseaudio[3068]: [pulseaudio] authkey.c: Failed to load authorization key '/var/lib/gdm/.config/pulse/cookie': No such file or directory Jul 15 11:57:33 localhost dbus-daemon[2521]: dbus[2521]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' Jul 15 11:57:33 localhost dbus[2521]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' Jul 15 11:57:33 localhost dbus[2521]: [system] Activation via systemd failed for unit 'dbus-org.bluez.service': Unit dbus-org.bluez.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.bluez.service' for details. Jul 15 11:57:33 localhost dbus-daemon[2521]: dbus[2521]: [system] Activation via systemd failed for unit 'dbus-org.bluez.service': Unit dbus-org.bluez.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.bluez.service' for details. Jul 15 11:57:33 localhost pulseaudio[3056]: [pulseaudio] authkey.c: Failed to open cookie file '/var/lib/gdm/.config/pulse/cookie': No such file or directory Jul 15 11:57:33 localhost pulseaudio[3056]: [pulseaudio] authkey.c: Failed to load authorization key '/var/lib/gdm/.config/pulse/cookie': No such file or directory Jul 15 11:57:41 localhost polkitd[2628]: Registered Authentication Agent for unix-session:2 (system bus name :1.24 [gnome-shell --mode=gdm], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale C) (In reply to Tom Wijsman (TomWij) from comment #11) > > Jul 14 22:26:23 localhost gdm-launch-environment][11463]: > > pam_systemd(gdm-launch-environment:session): Unknown parameter > > 'kill-session-processes=1', ignoring > > ^ Bummer 2, misconfiguration somewhere; though this might not be important. > I haven't configure it and it is not present after downgrade: # grep kill /etc/pam.d/* # journalctl -b | grep kill-session # > > Jul 14 22:26:23 localhost systemd-logind[2546]: Assertion 's->user->slice' > > failed at > > /var/tmp/portage/sys-apps/systemd-205/work/systemd-205/src/login/logind- > > session.c:463, function session_start_scope(). Aborting. > > ^ Bummer 3, assertion failing sounds bad; especially since it aborts. > It seems to be connected to gdm failure: # journalctl -b | grep session_start # > > Jul 14 22:26:23 localhost abrt[11466]: File > > '/usr/lib64/systemd/systemd-logind' seems to be deleted > > ^ Bummer 4, present on my system; can you check if the file is present for > you? > > Try emerging systemd again to restore it; if it still gives that error then > `emerge app-portage/portage-utils` and attach `qcheck sys-apps/systemd` > I've built the systemd yesterday along with gdm (205 -> 205): # ls -l /usr/lib64/systemd/systemd-logind -rwxr-xr-x 1 root root 239728 Jul 14 22:08 /usr/lib64/systemd/systemd-logind # qcheck sys-apps/systemd Checking sys-apps/systemd-205 ... * 942 out of 942 files are good > > Jul 14 22:26:23 localhost abrt[11466]: Saved core dump of pid 2546 > > (/usr/lib64/systemd/systemd-logind) to > > /var/spool/abrt/ccpp-2013-07-14-22:26:23-2546 (1110016 bytes) > > ^ Bummer 5, heh, it core dumps for that process; so the file is present?! > Yes > > Jul 14 22:26:23 localhost systemd[11471]: Failed at step PAM spawning > > /usr/lib/systemd/systemd: Operation not permitted > > ^ Bummer 7, pam configuration issue, I think this one needs > "session optional pam_systemd.so" at the bottom of /etc/pam.d/system-auth > # grep pam_systemd /etc/pam.d/* /etc/pam.d/system-auth:-session optional pam_systemd.so controllers=cpu,blkio,bfqio /etc/pam.d/system-login:-session optional pam_systemd.so > (In reply to Maciej Piechotka from comment #7) > > Created attachment 353296 [details] > > :0-greeter.log > > > > Strangely most of errors are in successful run as well. > > Do you see "failed to create drawable" in a succesful run? This is the error > I expect it would throw for me; but it doesn't, screen stays black but shows > my mouse which I can move. Both this for gdm or when I run gnome-shell > separately; so, I would expect to get this very same error. :/ > Yes. I also find it strange - the gdm 3.8 works perfectly fine. > Anyhow, unless it is just the systemd-logind file missing; our issue is > similar. systemd-logind file missing would not be fixed by gdm downgrade I guess...
(In reply to Tom Wijsman (TomWij) from comment #14) [...] > Sorry, I don't have time to follow up with upstream until August. > > Anyhow, I've digged into that second link and saw a mention of a > gdm-initial-setup user; so, I've added that user an ended up following these > instructions. > > https://github.com/GNOME/gnome-initial-setup/blob/master/gnome-initial-setup/ > README From its reading, looks like: InitialSetupEnable=True -> if that is not present, that user shouldn't be needed (!), or maybe you could try to set it to False explicitly I think we will need to sed data/gdm.schemas to change default from "True" to "False", maybe you could check how all this work for you (in summary, be sure gdm defaults to disable initial setup instead of current situation) > > The gdm-setup.session file I deduced from the following commit I found: > > https://mail.gnome.org/archives/commits-list/2012-April/msg04517.html > > After that, I no longer get the above error; which is progress! Therefore I > suggest OP to try the above as well. I don't understand what do you mean here, looks like gdm-setup.session doesn't exist :/ > > Sadly, my Gnome is so broken that I am experiencing a black screen; but I > think, I got a step further. After giving 777 permissions and gdm:gdm to > /run/user/* a few times (you said something about checking those > permissions, consider this a reminder; because they still are improper), I thought all this should be fixed in gdm-3.8.3.1: # Be sure /run/gdm is ready # https://help.gnome.org/admin/gdm/stable/security.html.en#gdmuser keepdir /run/gdm fowners root:gdm /run/gdm fperms 1777 /run/gdm What more is needed? > runnning `gdm` and looking into `journalctl -r` a few times I saw the > following error pop up: [...] This backtrace needs to be reported to upstream, please do (it will also detect if some duplicate bug is already existing as bugzilla.gnome.org compares backtraces when sending them) > (gnome-settings-daemon:5794): GnomeDesktop-CRITICAL **: > gnome_rr_output_info_get_geometry: assertion `GNOME_IS_RR_OUTPUT_INFO > (self)' failed > > The interesting part here is that it is compare_output_positions in xrandr > in make_xinerama_setup; so, the problem in my case lies with xinerama > perhaps. Looking at `euse -I xinerama` the relevent packages that have an > USE flag are gdm and gtk+; I do see a mention of gtk+ in above backtrace but > it's not near the actual failing code, which makes me a bit doubtful if I > can disable Xinerama here. > > Looking at `equery d x11-libs/libXinerama` and `equery d > x11-proto/xineramaproto` I do not see a direct dependency from anything else > in the above backtrace though; at best, I learn that mutter depends on it as > well, but that's probably not relevant. Removing libXinerama seems a bit > tricky as some applications I use depend on them, although I could attempt > to sacrifice them for a moment; but I'll try to at least disable the > xinerama USE flag and test it that way to see if there is an improvement. > > So, maybe there's something wrong with my xrandr causing xinerama to fail? > > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 > LVDS-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) > 382mm x 215mm > 1920x1080 60.0*+ 60.0 > 1680x1050 60.0 > 1400x1050 60.0 > 1280x1024 59.9 > 1280x960 59.9 > 1152x864 60.0 > 1024x768 59.9 > 800x600 59.9 > 640x480 59.4 > 720x400 59.6 > 640x400 60.0 > 640x350 59.8 > HDMI-1 disconnected (normal left inverted right x axis y axis) > DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) > 382mm x 215mm > 1920x1080 60.0*+ > > LVDS is internal laptop display, DVI is a shared port (between LVDS and > external DVI connector), HDMI is my external HDMI connector, there's also a > DVI connector on the side but there's nothing attached. Maybe Xinerama or > Gnome doesn't like the shared port concept here; in fact, Nouveau doesn't > like it either so I wouldn't be surprised to see it fail in other places as > well. > > Hopefully disabling the USE flag serves as a temporary solution; if not, I > guess we'll have to go through a lot more debugging. Or well, maybe slaves > still don't get access to the display and it now silently fails... I saw some fixes related with detection of size problems in clutter-1.14 branch: https://git.gnome.org/browse/clutter/log/?h=clutter-1.14 maybe they could be involved in your issue :/
Pacho, /run is on tmpfs nowadays, you need to create a proper tmpfiles.d conf file.
(In reply to Fabio Erculiani from comment #18) > Pacho, > /run is on tmpfs nowadays, you need to create a proper tmpfiles.d conf file. bleh, if you have one prepared, please let me know (if not, will try to prepare one myself when I have a bit more time). Thanks for pointing out the problem!
(In reply to Pacho Ramos from comment #17) > I don't understand what do you mean here, looks like gdm-setup.session > doesn't exist :/ Please read again; I have set my gdm to do its initial setup after reading about the user, that way it put gdm back into a sane state. This ends up removing the error about the slave bus access... Though, after experimenting for a day the error returned so I guess I need to repeat the instructions again; I suppose something gets corrupted by the problems that happen... > > Sadly, my Gnome is so broken that I am experiencing a black screen; but I > > think, I got a step further. After giving 777 permissions and gdm:gdm to > > /run/user/* a few times (you said something about checking those > > permissions, consider this a reminder; because they still are improper), > > I thought all this should be fixed in gdm-3.8.3.1: > # Be sure /run/gdm is ready > # https://help.gnome.org/admin/gdm/stable/security.html.en#gdmuser > keepdir /run/gdm > fowners root:gdm /run/gdm > fperms 1777 /run/gdm > > What more is needed? As lxnay mentions, /run is on tmpfs so those instructions do nearly nothing. > > runnning `gdm` and looking into `journalctl -r` a few times I saw the > > following error pop up: > [...] > > This backtrace needs to be reported to upstream, please do (it will also > detect if some duplicate bug is already existing as bugzilla.gnome.org > compares backtraces when sending them) https://bugzilla.gnome.org/show_bug.cgi?id=704286 > I saw some fixes related with detection of size problems in clutter-1.14 > branch: > https://git.gnome.org/browse/clutter/log/?h=clutter-1.14 > > maybe they could be involved in your issue :/ I don't see anything in the backtrace related to clutter though. As for xinerama testing; still a black screen, though my patch to temporarily deal with this stack trace at least lets gnome-settings-daemon live. Now I don't know where the next issue lies; so, I first have to deal with the initial system user and dbus rejected message again: dbus[2720]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.1529" (uid=0 pid=25688 comm="/usr/sbin/gdm ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.1530" (uid=0 pid=25691 comm="/usr/libexec/gdm-simple-slave --display-id /org/gn") The patch I wrote to undo the bad commit only affects the error message, and not the rejected send message output above; so, there's still something going on here. When using Debian files it proceeds though I'm not sure if it worked well, when using patched Gentoo files it times out and when using the default Gentoo files it gives above message. I would be happy to try proper tmpfiles.d configuration files for systemd... :) PS: On a side note, where are Gnome logs stored? In /var/log/gdm/ it is only updating :0.log and not the other ones. Any idea what may cause this as `journalctl -b` is tedious and doesn't log everything... :/ PS 2: I also get messages about missing service files, any idea about that? ** (gnome-settings-daemon:2572): DEBUG: Failed to set the environment: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
(In reply to Maciej Piechotka from comment #16) > Something like: > > ... journalctl ... Apart from it mentioning it doesn't support the controllers argument it looks extremely clean; therefore, we must focus on any warning or error we see, some might be the consequence of each other so I guess earlier warnings and errors are more important than later ones, especially errors. The main one being: Jul 14 22:26:23 localhost gdm[11439]: Failed to give slave programs access to the display. Trying to proceed. I don't have time to go upstream with this now until August, could you file a bug with them instead and proceed with upstream on trying to resolve this? Please file it at https://bugzilla.gnome.org/enter_bug.cgi and give us a link to the upstream bug, you can copy the number link in the top left for that. Thank you very much in advance... :)
(In reply to Tom Wijsman (TomWij) from comment #20) > (In reply to Pacho Ramos from comment #17) > > I don't understand what do you mean here, looks like gdm-setup.session > > doesn't exist :/ > > Please read again; I have set my gdm to do its initial setup after reading > about the user, that way it put gdm back into a sane state. This ends up > removing the error about the slave bus access... > > Though, after experimenting for a day the error returned so I guess I need > to repeat the instructions again; I suppose something gets corrupted by the > problems that happen... Ah, I went completely lost as I never tweaked that option and doesn't have anything related with gnome-initial-setup (how did you handle it? We don't have it packaged because it's a bit Fedora specific, see bug 463764) > As lxnay mentions, /run is on tmpfs so those instructions do nearly nothing. > OK, anyway, are them be wrongly created currently? If they are being created by gdm itself, it should work ok, in my case: ls -l /run/gdm/ -d drwx--x--x 4 root gdm 120 jul 14 20:12 /run/gdm/ > When using Debian files it proceeds though I'm not sure if it > worked well, when using patched Gentoo files it times out and when using the > default Gentoo files it gives above message. > What Debian files? Are you running gdm-3.8.3.1 from main tree? (it uses pam files from upstream instead of custom ones... not sure if it could be related :S) > I would be happy to try proper tmpfiles.d configuration files for systemd... > :) > > PS: On a side note, where are Gnome logs stored? In /var/log/gdm/ it is only > updating :0.log and not the other ones. Any idea what may cause this as > `journalctl -b` is tedious and doesn't log everything... :/ > I am using "journalctl" and it logs most of the stuff, the other stuff was in ":0.log" last time I checked > PS 2: I also get messages about missing service files, any idea about that? > ** (gnome-settings-daemon:2572): DEBUG: Failed to set the environment: > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > org.gnome.SessionManager was not provided by any .service files Looks like I don't have it in journalctl output (even if I got a lot of that kind of missing .service files warnings when using older Gnome and consolekit)
(In reply to Tom Wijsman (TomWij) from comment #21) > I don't have time to go upstream with this now until August, could you file > a bug with them instead and proceed with upstream on trying to resolve this? > Please file it at https://bugzilla.gnome.org/enter_bug.cgi and give us a > link to the upstream bug, you can copy the number link in the top left for > that. Thank you very much in advance... :) Yeah, please report the problem, I hope they won't have problems (now that we are running systemd), and I wouldn't report this myself as I don't suffer it Thanks
(In reply to Pacho Ramos from comment #22) > Ah, I went completely lost as I never tweaked that option and doesn't have > anything related with gnome-initial-setup (how did you handle it? We don't > have it packaged because it's a bit Fedora specific, see bug 463764) Read a third time, I've mentioned which link I followed as well as the additional steps I've done on top of that; it improves the situation. > > As lxnay mentions, /run is on tmpfs so those instructions do nearly nothing. > > > > OK, anyway, are them be wrongly created currently? If they are being created > by gdm itself, it should work ok, in my case: > ls -l /run/gdm/ -d > drwx--x--x 4 root gdm 120 jul 14 20:12 /run/gdm/ drwx--x--x 26 root gdm 560 Jul 15 18:25 /run/gdm/ That's not what this is about; it is about the user folders: $ ls -l /run/user/ -d drwxr-xr-x 4 root root 80 Jul 15 18:22 /run/user/ $ ls -l /run/user/ total 0 drwx------ 5 root root 100 Jul 15 18:14 0 drwx------ 5 tomwij tomwij 100 Jul 15 18:22 1000 # ls -l /run/user/* /run/user/0: total 0 drwx------ 2 root root 60 Jul 15 18:14 dconf drwx------ 3 root root 60 Jul 15 18:14 gnome-shell drwx------ 2 root root 40 Jul 15 18:14 pulse /run/user/1000: total 0 drwx------ 2 tomwij tomwij 60 Jul 15 21:34 dconf drwx------ 2 tomwij tomwij 120 Jul 15 18:22 keyring-qil3fa drwx------ 2 tomwij tomwij 100 Jul 15 18:22 pulse > > When using Debian files it proceeds though I'm not sure if it > > worked well, when using patched Gentoo files it times out and when using the > > default Gentoo files it gives above message. > > > > What Debian files? Are you running gdm-3.8.3.1 from main tree? (it uses pam > files from upstream instead of custom ones... not sure if it could be > related :S) Yes, from the Gentoo main tree. I just occasionally overwrite the dbus file with the Debian one or try to manually patch it when trying to fix that rejected message. > > I would be happy to try proper tmpfiles.d configuration files for systemd... > > :) > > > > PS: On a side note, where are Gnome logs stored? In /var/log/gdm/ it is only > > updating :0.log and not the other ones. Any idea what may cause this as > > `journalctl -b` is tedious and doesn't log everything... :/ > > > > I am using "journalctl" and it logs most of the stuff, the other stuff was > in ":0.log" last time I checked Same here, so the old greeter / slave files are gone by design I guess. I was wondering; how do I capture --debug output (the output the debug USE flag is supposed to add), because I don't seem to see that. A last resort option is to do strace but that might be tedious, it also doesn't log already running services... > > PS 2: I also get messages about missing service files, any idea about that? > > ** (gnome-settings-daemon:2572): DEBUG: Failed to set the environment: > > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > > org.gnome.SessionManager was not provided by any .service files > > Looks like I don't have it in journalctl output (even if I got a lot of that > kind of missing .service files warnings when using older Gnome and > consolekit) You are probably not running with debug enabled; I see the above in gdb, but for the sake of being able to debug the situation easier I'd like to be able to see all debug output at once. It's otherwise sometimes hard to figure out where it fails exactly... :)
[...] > That's not what this is about; it is about the user folders: > > $ ls -l /run/user/ -d I have the same permissions :/, in addition, I have: lrwxrwxrwx 1 root root 17 jul 15 22:18 X11-display -> /tmp/.X11-unix/X0 [...] > Yes, from the Gentoo main tree. I just occasionally overwrite the dbus file > with the Debian one or try to manually patch it when trying to fix that > rejected message. > What is the offending dbus file that looks to solve the issue when got from Debian?
(In reply to Pacho Ramos from comment #25) > [...] > > That's not what this is about; it is about the user folders: > > > > $ ls -l /run/user/ -d > > I have the same permissions :/, in addition, I have: > lrwxrwxrwx 1 root root 17 jul 15 22:18 X11-display -> /tmp/.X11-unix/X0 I'm not sure whether I have that entry, which folder is that in? > [...] > > Yes, from the Gentoo main tree. I just occasionally overwrite the dbus file > > with the Debian one or try to manually patch it when trying to fix that > > rejected message. > > > > What is the offending dbus file that looks to solve the issue when got from > Debian? Hmm, actually appears to be the file that comes from gdm; I think I might have confused them, I'm now not sure if Gentoo differs from it. As for my own version, I have removed all send_destination attributes there and that's the one where it is guaranteed to no longer reject messages; however, that causes it to hang at that point. I'm a bit tired to run through them again; but well, as it works for you as well as on 3.8.0 for him we can be assured that the problem does not really lie with the dbus rules which should be equal. If not, I'll have to just compare them against a stage3 install... Although, setting up the initial session / user as I explained in an earlier comment seems to make it not hang there and appears to be giving me back proper Timed Login information in debug; but well, I should eventually be able to not have to rely on a series of hack, and I think getting /run to work would be a reliable way to achieve that. It might give you the impression that it is good, but that's merely because I ran `chmod -R 777 /run/user` and `chown -R gdm:gdm /run/user` a few times; now I guess I have a working /run/user, but the rest is broken and since it is a tmpfs it doesn't remain working. So, later the story repeats and I get permission denieds on /run/user/0/dconf, /run/user/0/pulse, /run/user/1000/dconf, and the list goes on; some are not even output to the journal, I think... Like I said before, I'm not certain if I have a total view of all available debugging output; because I would expect some parts to log a bit more than they already do...
(In reply to Tom Wijsman (TomWij) from comment #26) > I'm not sure whether I have that entry, which folder is that in? > # ls -l /run/user/* /run/user/0: total 0 /run/user/1001: ls: no se puede acceder a /run/user/1001/gvfs: Permiso denegado total 0 lrwxrwxrwx 1 root root 17 jul 15 22:18 X11-display -> /tmp/.X11-unix/X0 drwx------ 2 pacho users 60 jul 16 08:42 dconf drwx------ 3 pacho users 60 jul 15 22:18 gnome-shell d????????? ? ? ? ? ? gvfs drwx------ 2 pacho users 40 jul 15 22:19 gvfs-burn drwx------ 2 pacho users 120 jul 15 22:18 keyring-NzjNfv drwx------ 2 pacho users 100 jul 15 22:18 pulse /run/user/101: total 0 lrwxrwxrwx 1 root root 17 jul 15 22:08 X11-display -> /tmp/.X11-unix/X0 drwx------ 2 gdm gdm 60 jul 15 22:18 dconf drwx------ 3 gdm gdm 60 jul 15 22:09 gnome-shell drwx------ 2 gdm gdm 40 jul 15 22:19 pulse [...] > Hmm, actually appears to be the file that comes from gdm; I think I might > have confused them, I'm now not sure if Gentoo differs from it. As for my > own version, I have removed all send_destination attributes there and that's > the one where it is guaranteed to no longer reject messages; however, that > causes it to hang at that point. We are using upstream gdm dbus stuff, we don't touch anything related with that :/ > > I'm a bit tired to run through them again; but well, as it works for you as > well as on 3.8.0 for him we can be assured that the problem does not really > lie with the dbus rules which should be equal. If not, I'll have to just > compare them against a stage3 install... > > Although, setting up the initial session / user as I explained in an earlier > comment seems to make it not hang there and appears to be giving me back > proper Timed Login information in debug; but well, I should eventually be > able to not have to rely on a series of hack, and I think getting /run to > work would be a reliable way to achieve that. > > It might give you the impression that it is good, but that's merely because > I ran `chmod -R 777 /run/user` and `chown -R gdm:gdm /run/user` a few times; > now I guess I have a working /run/user, but the rest is broken and since it > is a tmpfs it doesn't remain working. > > So, later the story repeats and I get permission denieds on > /run/user/0/dconf, /run/user/0/pulse, /run/user/1000/dconf, and the list > goes on; some are not even output to the journal, I think... Like I said > before, I'm not certain if I have a total view of all available debugging > output; because I would expect some parts to log a bit more than they > already do... No idea why you get that behavior, I haven't seen any distribution needing to provide a tmpfiles.d file to handle /run/user/*, and the gvfs permission denied problem I hit looks to be expected: https://bugzilla.gnome.org/show_bug.cgi?id=560658 But I need to go now to the job (you always catch me at the start and the end of the day ;))
Filed another bug; see URL field, which reflects the "failed to give ..." error.
Bummer, bug was closed upstream and deemed "works as is". For me; I can await resolution on the bug I filed, but for you or the issue we might both be experiencing we've ran into a dead end. We'll have to look at other warnings and errors and figure out where they come from; or, in your case, you could run a bisect. Do you know how you need to do run a bisect? Otherwise we can prepare a patchset that properly applies for you and give you instructions on how to do this. I did a full bisect between 3.4 and 3.8 which are 350 patches; so, I think a bisect between 3.8.0 and 3.8.3 will not involve much patches and thus won't take so long. Given the preparation, it basically involves copying to and removing some files from a directory and emerging and testing again and again; although, I'm not so sure if the actual problem lies with gdm in your case which can cause some trouble...
Problem solved with me with the g-s-d patch in the See Also bug; but well, it's a different symptom than what you see. Unless your gnome-settings-daemon is not present...
+*gnome-settings-daemon-3.8.4 (20 Jul 2013) + + 20 Jul 2013; Pacho Ramos <pacho@gentoo.org> + +gnome-settings-daemon-3.8.4.ebuild, -gnome-settings-daemon-3.8.3.ebuild: + Version bump, drop old + This should fix tomwij problem, regarding Maciej one, please try with this one and, if still valid: 1. As you say 3.8.0 wasn't affected, try to copy 3.8.3.1 as 3.8.0 -> if it breaks, the breakage could be related with using the new upstream pam files, if not 2. Try to bump locally to each 3.8 minor version from upstream until find the one introducing the problem. 3. Once located, you can try to bisect it to find the offending commit
(In reply to Pacho Ramos from comment #31) > +*gnome-settings-daemon-3.8.4 (20 Jul 2013) > + > + 20 Jul 2013; Pacho Ramos <pacho@gentoo.org> > + +gnome-settings-daemon-3.8.4.ebuild, -gnome-settings-daemon-3.8.3.ebuild: > + Version bump, drop old > + > > This should fix tomwij problem, regarding Maciej one, please try with this > one (...) This fixed my problem.
(In reply to Maciej Piechotka from comment #32) > This fixed my problem. Awesome!
