Bug 552279 - updated daemons restart at +19 nice
updated daemons restart at +19 nice
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum (Show other bugs)
5.4
All Linux
urgent Severity high
: rc
: ---
Assigned To: James Antill
BaseOS QE Security Team
: ZStream
Depends On:
Blocks: 743405 758678 758797
  Show dependency treegraph
 
Reported: 2010-01-04 09:57 EST by Martin Poole
Modified: 2014-01-21 01:16 EST (History)
7 users (show)

See Also:
Fixed In Version: yum-3.2.22-39.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 573230 (view as bug list)
Environment:
Last Closed: 2012-02-21 01:39:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Martin Poole 2010-01-04 09:57:58 EST
Description of problem:

Startup script for yum-udpatesd sets priority at +19

When yum-updatesd updates daemons and they restart they are
started at the same priority changing system behaviour

Version-Release number of selected component (if applicable):

yum-updatesd-0.9-2.el5

How reproducible:

Always

Steps to Reproduce:
1. install system at 5.3
2. let yum-updatesd perform updates
3. ps ax -o ni,args
  
Actual results:

restarted daemons are at +19

Expected results:

daemons should be at normal priority of 0

Additional info:

Easiest fix would be to remove the +19 from the yum-updatesd startup script, although this would also produce a change in load behaviour.

One could argue that the daemon should set its own priority internally for operations that are regarded as heavy, whilst ensuring that operations like execution of %pre/%post-install should be at priority 0, but this would likely require extensive, probably intrusive, changes that probably cannot be justified at this point in the RHEL5 life-cycle.
Comment 1 Mike Lococo 2010-01-26 12:33:06 EST
I confirm this bug exactly as reported, and it's fairly problematic in my environment.  It doesn't take long for a process that restarts lots of processes like sshd or puppetd (automatic configuration management software) to get updated by yum-updatesd and inherit the high nice value.  From there the problem spreads very quickly to critical system processes via normal system administration procedures and routine process restarts.

At this point, I pretty much need to restart all my red-hat servers once a week to reset nice values.
Comment 3 Mike Lococo 2010-07-30 18:18:53 EDT
Any progress on this?  The original report in January proposes a one-line patch to the yum-updatesd init script which hasn't received a response.  If yum-updatesd must force a nice-value on every process it updates, forcing 0 is *much* saner than forcing +19.

Obviously a more robust fix would be desirable, but I don't think that should block a one-liner which is a clear win from being implemented in the meantime.
Comment 4 James Antill 2010-08-02 11:06:10 EDT
This seems like something rpm should fix up (change nice value back to 0 when running scriptlets).

I don't mind applying the one line "patch" though.
Comment 5 RHEL Product and Program Management 2010-08-09 15:42:01 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 6 Mike Lococo 2010-08-09 16:15:54 EDT
James, I take it that the latest update by RHEL Product and Program Management means that you initiated some Red-Hat internal process to push this fix and the request was denied?

That is unfortunate, as the fix is so simple and the problem is in my opinion fairly severe.  Any process which is routinely restarted ends up niced +19 within weeks due to some parent process like SSH, puppet, or crond getting updated.
Comment 7 James Antill 2010-08-10 15:38:02 EDT
 Yeh, I proposed to fix it for 5.6 and it got rejected.
 I've proposed it for 5.7, but it depends more on how much the two customer tickets push for it than how much I want to do it :).

 On the other hand, it's very likely to be fixed in any future updates for yum-updatesd ... so if you want to run sed on the init.d file, that's unlikely to be undone.
Comment 9 RHEL Product and Program Management 2011-05-31 11:23:09 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 10 Mike Lococo 2011-10-07 16:45:12 EDT
This has been re-reported against Fedora 14 in Bug 676427.  It's not clear to me how to add additional Products to a bug, or if it's possible.  It's worth noting that this is still affecting customers, though.
Comment 11 Mike Lococo 2011-10-07 16:58:14 EDT
Moving to yum-cron is sometimes proposed as a workaround for this bug, but it
suffers from the same issue (at nice +10 instead of nice +19).  Details and a
workaround are available in Bug 742363, which is probably worth adding as a "see also".

This means that there is no way to configure a standalone RHEL5 system to
automatically update without having its services reniced to some arbitrary
value.  The specific nice value isn't configurable except by hacking scripts
that can be overwritten on package update since they're not marked as
config-files and don't receive the protection from yum-updates that entails.

I suppose the supported solution is the Satellite/Spacewalk tools, but that's
entirely overkill for small/medium sized shops.
Comment 21 errata-xmlrpc 2012-02-21 01:39:55 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0273.html

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