Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
After updating several VMs to 6.8, we are finding gconfd-2 processes running at high CPU and memory that can only be killed manually to resolve.
On one VM that had 8 or more processes running at high utilization, customer switched to runlevel 3, killed all the gconfd-2 process that were running, and everything went back to normal.
Version-Release number of selected component (if applicable):
GConf2-2.28.0-6.el6.x86_64
How reproducible:
Customer's servers updated to 6.8. Users log in and out of the system under normal use.
Steps to Reproduce:
Issue occurs on its own after some time on these VMs. We have been unable to reproduce it here.
Actual results:
gconfd-2 processes (seemingly related to gdm) remain active after users log out. When the user logs out, gnome-session typically fires up gconftool-2 --shutdown to shut down gconfd, but that does not appear to be happening.
Expected results:
gconfd-2 processes should be shut down by gnome-session when the user logs out.
Additional Information:
Looking at the xsession-errors:
(polkit-gnome-authentication-agent-1:8629): polkit-gnome-1-WARNING **: Error enumerating temporary authorizations: Remote Exception invoking org.freedesktop.PolicyKit1.Authority.EnumerateTemporaryAuthorizations() on /org/freedesktop/PolicyKit1/Authority at name org.freedesktop.PolicyKit1: org.freedesktop.PolicyKit1.Error.Failed: Cannot determine session the caller is in
gnome-settings-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5.
rhsm-icon: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5.
gdu-notification-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5.
gnome-volume-control-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5.
gpk-update-icon: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5.
gnome-screensaver: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5.
polkit-gnome-authentication-agent-1: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5.
bluetooth-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5.
Why are we trying to connect over localhost port 5? This seems odd. is there an orphaned lock too?
Xlib: extension "VMWARE_CTRL" missing on display "127.0.0.1:5".
Why is this missing? Have we verified packages on the system? Did an update complete half-finished?
gnome-session.log.8027:
restart_syscall(<... resuming interrupted call ...>) = 1
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"", 4096}], msg_controllen=0, msg_flags=0}, 0) = 0
write(2, "gnome-session: Fatal IO error 11"..., 93) = 93
writev(18, [{"GIOP\1\2\1\5\0\0\0\0", 12}], 1) = 12
close(18) = 0
writev(16, [{"GIOP\1\2\1\5\0\0\0\0", 12}], 1) = 12
close(16) = 0
close(15) = 0
close(14) = 0
exit_group(1) = ?
+++ exited with 1 +++
More resource unavailable...
gnome-session.log.8062:
read(19, <unfinished ...>
+++ exited with 1 +++
xsession-errors isnt very useful here
# ps -ef | grep gnome-session
gdm 8331 8315 0 10:34 ? 00:00:00 /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWindow/
root 8395 7991 0 10:35 pts/0 00:00:00 grep gnome-session
gdm 9278 8931 0 Sep28 ? 00:00:05 /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWindow/
This is what I get after using logging in with VNC.
# ps -ef | grep gnome-session
sdlinden 8492 8460 0 10:38 ? 00:00:00 gnome-session
root 8685 7991 0 10:38 pts/0 00:00:00 grep gnome-session
gdm 9278 8931 0 Sep28 ? 00:00:05 /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWindow/
This is after logging out of VNC.
# ps -ef | grep gnome-session
gdm 8720 8704 1 10:38 ? 00:00:00 /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWindow/
root 8756 7991 0 10:38 pts/0 00:00:00 grep gnome-session
gdm 9278 8931 0 Sep28 ? 00:00:05 /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWindow/
gdm 9285 1 0 Sep28 ? 00:00:27 /usr/libexec/gconfd-2
gdm 9399 1 0 07:11 ? 00:00:00 /usr/libexec/gconfd-2
It looks like the gconfd-2 daemons are owned by gdm
gconfd-2 should be shut down by gnome-session when the user logs out
gnome-session should be running under the userid of the user who is logged in
The core dump tells me that gconfd-2 is polling but it's not actually doing anything
Core was generated by `/usr/libexec/gconfd-2'.
#0 0x00000036b58df248 in __poll (fds=0x53b8bc00, nfds=15,
timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:83
83 return INLINE_SYSCALL (poll, 3, CHECK_N (fds, nfds), nfds, timeout);
(gdb) bt
#0 0x00000036b58df248 in __poll (fds=0x53b8bc00, nfds=15,
timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:83
#1 0x00000036b70449f9 in g_main_context_poll (context=0x24ff2c0, block=1, dispatch=
1, self=<value optimized out>) at gmain.c:3405
#2 g_main_context_iterate (context=0x24ff2c0, block=1, dispatch=1,
self=<value optimized out>) at gmain.c:3087
#3 0x00000036b70451a5 in g_main_loop_run (loop=0x3f70be0) at gmain.c:3300
#4 0x000000000040aa88 in gconf_main (argc=<value optimized out>,
argv=<value optimized out>) at gconfd.c:1066
#5 main (argc=<value optimized out>, argv=<value optimized out>) at gconfd.c:940
(gdb)
No hardening scripts have been run against the system.
Red Hat Enterprise Linux 6 transitioned to the Production 3 Phase on May 10, 2017. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.
The official life cycle policy can be reviewed here:
http://redhat.com/rhel/lifecycle
This issue does not appear to meet the inclusion criteria for the Production Phase 3 and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:
https://access.redhat.com
Description of problem: After updating several VMs to 6.8, we are finding gconfd-2 processes running at high CPU and memory that can only be killed manually to resolve. On one VM that had 8 or more processes running at high utilization, customer switched to runlevel 3, killed all the gconfd-2 process that were running, and everything went back to normal. Version-Release number of selected component (if applicable): GConf2-2.28.0-6.el6.x86_64 How reproducible: Customer's servers updated to 6.8. Users log in and out of the system under normal use. Steps to Reproduce: Issue occurs on its own after some time on these VMs. We have been unable to reproduce it here. Actual results: gconfd-2 processes (seemingly related to gdm) remain active after users log out. When the user logs out, gnome-session typically fires up gconftool-2 --shutdown to shut down gconfd, but that does not appear to be happening. Expected results: gconfd-2 processes should be shut down by gnome-session when the user logs out. Additional Information: Looking at the xsession-errors: (polkit-gnome-authentication-agent-1:8629): polkit-gnome-1-WARNING **: Error enumerating temporary authorizations: Remote Exception invoking org.freedesktop.PolicyKit1.Authority.EnumerateTemporaryAuthorizations() on /org/freedesktop/PolicyKit1/Authority at name org.freedesktop.PolicyKit1: org.freedesktop.PolicyKit1.Error.Failed: Cannot determine session the caller is in gnome-settings-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5. rhsm-icon: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5. gdu-notification-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5. gnome-volume-control-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5. gpk-update-icon: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5. gnome-screensaver: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5. polkit-gnome-authentication-agent-1: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5. bluetooth-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server 127.0.0.1:5. Why are we trying to connect over localhost port 5? This seems odd. is there an orphaned lock too? Xlib: extension "VMWARE_CTRL" missing on display "127.0.0.1:5". Why is this missing? Have we verified packages on the system? Did an update complete half-finished? gnome-session.log.8027: restart_syscall(<... resuming interrupted call ...>) = 1 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"", 4096}], msg_controllen=0, msg_flags=0}, 0) = 0 write(2, "gnome-session: Fatal IO error 11"..., 93) = 93 writev(18, [{"GIOP\1\2\1\5\0\0\0\0", 12}], 1) = 12 close(18) = 0 writev(16, [{"GIOP\1\2\1\5\0\0\0\0", 12}], 1) = 12 close(16) = 0 close(15) = 0 close(14) = 0 exit_group(1) = ? +++ exited with 1 +++ More resource unavailable... gnome-session.log.8062: read(19, <unfinished ...> +++ exited with 1 +++ xsession-errors isnt very useful here # ps -ef | grep gnome-session gdm 8331 8315 0 10:34 ? 00:00:00 /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWindow/ root 8395 7991 0 10:35 pts/0 00:00:00 grep gnome-session gdm 9278 8931 0 Sep28 ? 00:00:05 /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWindow/ This is what I get after using logging in with VNC. # ps -ef | grep gnome-session sdlinden 8492 8460 0 10:38 ? 00:00:00 gnome-session root 8685 7991 0 10:38 pts/0 00:00:00 grep gnome-session gdm 9278 8931 0 Sep28 ? 00:00:05 /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWindow/ This is after logging out of VNC. # ps -ef | grep gnome-session gdm 8720 8704 1 10:38 ? 00:00:00 /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWindow/ root 8756 7991 0 10:38 pts/0 00:00:00 grep gnome-session gdm 9278 8931 0 Sep28 ? 00:00:05 /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWindow/ gdm 9285 1 0 Sep28 ? 00:00:27 /usr/libexec/gconfd-2 gdm 9399 1 0 07:11 ? 00:00:00 /usr/libexec/gconfd-2 It looks like the gconfd-2 daemons are owned by gdm gconfd-2 should be shut down by gnome-session when the user logs out gnome-session should be running under the userid of the user who is logged in The core dump tells me that gconfd-2 is polling but it's not actually doing anything Core was generated by `/usr/libexec/gconfd-2'. #0 0x00000036b58df248 in __poll (fds=0x53b8bc00, nfds=15, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:83 83 return INLINE_SYSCALL (poll, 3, CHECK_N (fds, nfds), nfds, timeout); (gdb) bt #0 0x00000036b58df248 in __poll (fds=0x53b8bc00, nfds=15, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:83 #1 0x00000036b70449f9 in g_main_context_poll (context=0x24ff2c0, block=1, dispatch= 1, self=<value optimized out>) at gmain.c:3405 #2 g_main_context_iterate (context=0x24ff2c0, block=1, dispatch=1, self=<value optimized out>) at gmain.c:3087 #3 0x00000036b70451a5 in g_main_loop_run (loop=0x3f70be0) at gmain.c:3300 #4 0x000000000040aa88 in gconf_main (argc=<value optimized out>, argv=<value optimized out>) at gconfd.c:1066 #5 main (argc=<value optimized out>, argv=<value optimized out>) at gconfd.c:940 (gdb) No hardening scripts have been run against the system.