Bug 1450620

Summary: [abrt] gnome-settings-daemon: _g_log_abort(): gsd-power killed by signal 5
Product: [Fedora] Fedora Reporter: Christian Stadelmann <fedora>
Component: gnome-settings-daemonAssignee: Bastien Nocera <bnocera>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 26CC: bnocera, fmuellner, klember, mkasik, ofourdan, rstrode, tiagomatos
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/f74725b981c9c6510fe0eaa0fbcf6a94e673b231
Whiteboard: abrt_hash:a5bb5b46b89253af9e9d834ed5e1499bf837ae9a;VARIANT_ID=workstation;
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-05-14 09:54:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: core_backtrace
none
File: cpuinfo
none
File: dso_list
none
File: limits
none
File: proc_pid_status none

Description Christian Stadelmann 2017-05-14 00:47:24 UTC 
Version-Release number of selected component:
gnome-settings-daemon-3.24.2-1.fc26

Additional info:
reporter:       libreport-2.9.1
backtrace_rating: 4
cmdline:        /usr/libexec/gsd-power
crash_function: _g_log_abort
executable:     /usr/libexec/gsd-power
journald_cursor: s=598c4bad5b9d4f9da9715cdc6eb131eb;i=fd80d;b=5d18ff2fc78d49cebad64c1263777e82;m=134d752b4;t=54f71361e6071;x=3db7bbfa326913f
kernel:         4.11.0-2.fc26.x86_64
rootdir:        /
runlevel:       N 5
type:           CCpp

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 _g_log_abort at gmessages.c:549
 #1 g_log_default_handler at gmessages.c:3036
 #4 g_thread_new at gthread.c:830
 #5 g_get_worker_context at gmain.c:5839
 #6 g_task_thread_pool_init at gtask.c:1977
 #7 g_task_get_type at gtask.c:592
 #8 ensure_required_types at gdbusprivate.c:231
 #9 _g_dbus_initialize at gdbusprivate.c:1927
 #10 g_bus_get at gdbusconnection.c:7335
 #11 register_manager_dbus at gsd-power-manager.c:3046
Comment 1 Christian Stadelmann 2017-05-14 00:47:32 UTC 
Created attachment 1278543 [details]
File: backtrace
Comment 2 Christian Stadelmann 2017-05-14 00:47:34 UTC 
Created attachment 1278544 [details]
File: core_backtrace
Comment 3 Christian Stadelmann 2017-05-14 00:47:35 UTC 
Created attachment 1278545 [details]
File: cpuinfo
Comment 4 Christian Stadelmann 2017-05-14 00:47:37 UTC 
Created attachment 1278546 [details]
File: dso_list
Comment 5 Christian Stadelmann 2017-05-14 00:47:39 UTC 
Created attachment 1278547 [details]
File: limits
Comment 6 Christian Stadelmann 2017-05-14 00:47:41 UTC 
Created attachment 1278548 [details]
File: proc_pid_status
Comment 7 Christian Stadelmann 2017-05-14 00:56:05 UTC 
Every time GDM starts on my machine, I get several gnome-settings-daemon processes running under the gdm user crashing. This affects:
* xsettings plugin
* print-notifications plugin
* power plugin
* wacom plugin
* media-keys plugin
* a11y-keyboard plugin
* clipboard plugin
* housekeeping plugin
* xrandr plugin
* smartcard plugin

I can reproduce this on any boot. Some other gsd-* processes run successfully.

It seems like all the crashed processes are being replaced by a "gnome-session-failed" process each.
Comment 8 Christian Stadelmann 2017-05-14 02:30:48 UTC 
All the processes fail during thread creation with errno EAGAIN in pthread_create called from glib. A look at the "limits" file reveals that the process limit is 100, which could be reached by gdm/gnome-shell/XWayland + 10…20 gnome-settings-daemon processes. But why is the limit so low?
Comment 9 Christian Stadelmann 2017-05-14 02:47:40 UTC 
According to

> $ systemctl show user-42.slice

and

> $ systemctl show session-c8.scope

(that's where all the gsd-processes are running), the limit should be way higher. for user-42.slice it should be TasksMax=10813, for session-c8.scope TasksMax=18446744073709551615
Comment 10 Christian Stadelmann 2017-05-14 09:54:04 UTC 
This crasher was caused by a misconfiguration on my computer in `/etc/security/limits.d/`, where "nproc" was set to 100 for many users including gdm. Raising the limit and rebooting resulted in a system working completely fine.

Sorry for the noise.