This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 676427 - yum-updatesd runs with "nice 19", and that is inherited when it restarts services
yum-updatesd runs with "nice 19", and that is inherited when it restarts serv...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: yum-updatesd (Show other bugs)
14
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: James Antill
Fedora Extras Quality Assurance
:
: 676425 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-09 15:11 EST by Edgar Hoch
Modified: 2012-08-16 09:29 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-16 09:29:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Example part of /var/log/yum.log that corresponds to the update step of yum-updatesd when sshd was restarted. (10.53 KB, text/plain)
2011-02-09 15:11 EST, Edgar Hoch
no flags Details

  None (edit)
Description Edgar Hoch 2011-02-09 15:11:21 EST
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
Comment 1 Edgar Hoch 2011-02-09 17:07:24 EST
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.
Comment 2 Edgar Hoch 2011-08-18 08:07:20 EDT
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?
Comment 3 Edgar Hoch 2011-08-18 08:10:16 EDT
*** Bug 676425 has been marked as a duplicate of this bug. ***
Comment 4 James Antill 2011-08-18 09:45:01 EDT
 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.
Comment 5 Orion Poplawski 2011-09-29 16:30:24 EDT
yum-cron suffers from the same problem (although with nice 10 instead of 19), see related bug (with fix).
Comment 6 Mike Lococo 2011-10-07 16:47:05 EDT
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.
Comment 7 Mike Lococo 2011-10-07 17:03:28 EDT
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.
Comment 8 Fedora End Of Life 2012-08-16 09:29:17 EDT
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

Note You need to log in before you can comment on or make changes to this bug.