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.
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.
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.
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.
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.
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.
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.
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.
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.
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