Created attachment 477898 [details] Example part of /var/log/yum.log that corresponds to the update step of yum-updatesd when sshd was restarted. Description of problem: Today we recognize that processes we have started with a remote shell using ssh have a nice of 19. But we have not started them with any nice. We detected that /usr/sbin/sshd is running with nice 19. Subprocesses like ssh logins inherit the nice of the daemon. This is the reason why all remote logins with ssh also have nice 19. But why is /usr/sbin/sshd running with nice 19? We checked our hosts and found that /usr/sbin/sshd was restarted today on all our Fedora 14 hosts. But the restart time (the time shown by "ps -efl | grep /usr/sbin/sshd" is different on each hosts. We also found that this start time corresponds to a yum-updatesd update step we found in /var/log/yum.log (a set of package updates nearly at the same time). We found this correspondence on all our Fedora 14 hosts. Because of the timestamps in /var/log/yum.log and the start time of sshd I speculate that it may have to do with one of these packages: glibc-2.13-1.x86_64 glibc-common-2.13-1.x86_64 glibc-headers-2.13-1.x86_64 glibc-devel-2.13-1.x86_64 selinux-policy-3.9.7-29.fc14.noarch setroubleshoot-server-3.0.25-1.fc14.x86_64 Or it may have to do something with yum or yum-updatesd or with sshd? I checked the scripts of the rpm packages for sshd (rpm -q --scripts ...package list from yum.log... | grep sshd) but nothing was found. I don't know what program has restarted /usr/sbin/sshd and why. A temporary workaround without rebooting the host is the following: Log in as root (or using su or sudo) and start "renice 0 PID" where PID is the pid of /usr/sbin/sshd. Then log out and log in again. Version-Release number of selected component (if applicable): yum-updatesd-0.9-3.fc12.noarch yum-3.2.28-5.fc14.noarch yum-langpacks-0.1.5-3.fc14.noarch yum-metadata-parser-1.1.4-2.fc14.x86_64 yum-plugin-changelog-1.1.28-1.fc14.noarch yum-plugin-downloadonly-1.1.28-1.fc14.noarch yum-plugin-fastestmirror-1.1.28-1.fc14.noarch yum-plugin-filter-data-1.1.28-1.fc14.noarch yum-plugin-keys-1.1.28-1.fc14.noarch yum-plugin-list-data-1.1.28-1.fc14.noarch yum-plugin-merge-conf-1.1.28-1.fc14.noarch yum-plugin-post-transaction-actions-1.1.28-1.fc14.noarch yum-plugin-priorities-1.1.28-1.fc14.noarch yum-plugin-protectbase-1.1.28-1.fc14.noarch yum-plugin-refresh-updatesd-1.1.28-1.fc14.noarch yum-plugin-security-1.1.28-1.fc14.noarch yum-plugin-tsflags-1.1.28-1.fc14.noarch yum-plugin-verify-1.1.28-1.fc14.noarch yum-plugin-versionlock-1.1.28-1.fc14.noarch yum-presto-0.6.2-2.fc14.noarch yum-utils-1.1.28-1.fc14.noarch glibc-2.13-1.i686 glibc-2.13-1.x86_64 glibc-common-2.13-1.x86_64 glibc-devel-2.13-1.i686 glibc-devel-2.13-1.x86_64 glibc-headers-2.13-1.x86_64 glibc-static-2.13-1.x86_64 gnome-applet-sshmenu-3.18-1.fc13.noarch kernel-2.6.35.10-74.fc14.x86_64 kernel-2.6.35.6-45.fc14.x86_64 kernel-devel-2.6.35.10-74.fc14.x86_64 kernel-devel-2.6.35.6-45.fc14.x86_64 kernel-doc-2.6.35.10-74.fc14.noarch kernel-headers-2.6.35.10-74.fc14.x86_64 ksshaskpass-0.5.3-1.fc14.x86_64 libssh-0.4.8-1.fc14.x86_64 libssh2-1.2.4-1.fc14.i686 libssh2-1.2.4-1.fc14.x86_64 mussh-0.7-4.fc12.noarch openssh-5.5p1-24.fc14.2.x86_64 openssh-askpass-5.5p1-24.fc14.2.x86_64 openssh-clients-5.5p1-24.fc14.2.x86_64 openssh-server-5.5p1-24.fc14.2.x86_64 pam_ssh-1.97-4.fc14.x86_64 How reproducible: It appears today (2011-02-09) after an automatic package update by yum-updatesd. It seems that only Fedora 14 is affected. Steps to Reproduce: 1. Install Fedora 14 including updates before 2011-02-09. 2. Create yum repositories as available at 2011-02-09 and configure yum to use these repos. 3. Start sshd. 4. Check that sshd runs with nice 0. 5. Start yum-updatesd. 6. Wait until yum-updatesd has installed the updated packages as of 2011-02-09. 7. Check if sshd was restarted and what the nice is. Actual results: sshd runs with nice 19. Expected results: sshd should run with nice 0. Additional info: The output of "ps -efl |grep /usr/sbin/sshd" on the example host that corresponds to the yum.log part in the attachment: 5 S root 15749 1 0 99 19 - 18767 poll_s 12:42 ? 00:00:00 /usr/sbin/sshd
I found some more informations: # rpm -q --scripts glibc shows as output among others: postinstall program: /usr/sbin/glibc_post_upgrade.x86_64 See also: # file /usr/sbin/glibc_post_upgrade.x86_64 /usr/sbin/glibc_post_upgrade.x86_64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, stripped # strings - /usr/sbin/glibc_post_upgrade.x86_64 | grep sshd /usr/sbin/sshd /etc/rc.d/init.d/sshd It seems that it may be the postinstall program of glibc which restarts sshd. But why is sshd started with nice 19 now? I earlier Fedora versions sshd runs with nice 0 and yum-updatesd with nice 19.
The problem still exists on Fedora 14. I have noticed it again because the was a glibc update on August 13th 2011 which have restarted sshd. The causal problem may be that yum-updatesd is started with daemon +19 'yum-updatesd &' in /etc/init.d/yum-updatesd, which inherits the nice 19 to restated processes. But yum-updated is running as root and may increase its nice level to 0 to restart processes - or at least this may be done when running rpm scripts, so that /usr/sbin/glibc_post_upgrade.x86_64 runs with nice 0. Is there a solution? I am not sure if the same problem exists on Fedora 15. yum-updatesd is also started wit daemon +19 'yum-updatesd &' and glibc also starts /usr/sbin/glibc_post_upgrade.x86_64 (and /usr/sbin/glibc_post_upgrade.i386) in the postinstall script, but sshd seems to run with nice 0. There was an update of glibc at August 10th, 2011, and I have only one host running since before the update of glibc without reboot. But there sshd. is running with nice 0. Has Fedora 15 a solution for this problem that is missing in Fedora 14?
*** Bug 676425 has been marked as a duplicate of this bug. ***
You can run yum-cron instead of yum-updatesd, it is a known bug in yum-updatesd but it isn't at the top of anybodys TODO list atm.
yum-cron suffers from the same problem (although with nice 10 instead of 19), see related bug (with fix).
This was previously reported against RHEL5 in January of 2010 in Bug 552279. Not sure if this should be duped, or added as a "see also", or what. Also can't figure out how to modify any of those fields, perhaps I don't have permission.
Moving to yum-cron is sometimes proposed as a workaround for this bug, but as noted in Comment 5, it suffers from the same issue. Details and a workaround are available in Bug 742363 (already added as a see-also to this bug). packagekit-cron is probably the last option for doing automatic updates on a standalone system. I haven't tested it to see whether it suffers from a similar bug, but it's a more ambitious framekwork than either yum-updatesd or yum-cron so it might address this issue better. Alternately one would have to look at satellite or spacewalk, which are pretty heavyweight solutions generally targeted toward large shops.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping