dnf replacement for yum-cron

drago01 drago01 at gmail.com
Mon Jun 16 15:41:28 UTC 2014

On Mon, Jun 16, 2014 at 5:37 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> drago01 wrote:
>> On Mon, Jun 16, 2014 at 5:14 PM, Matthew Miller
>> <mattdm at fedoraproject.org> wrote:
>>> On Mon, Jun 16, 2014 at 05:06:45PM +0200, drago01 wrote:
>>>> > That's not the most descriptiony of all descriptions ever, but if the name
>>>> > is any indication, it is just a thing which keeps the cache up to date.
>>>> > yum-cron can actually apply updates  [....]
>>>> That sounds dangerous ... updates are not really atomic (i.e not at
>>>> all) doing them silently in the background is a very bad idea.
>>> Yet, it works pretty well most of the time. I've done it at decent scale on
>>> production machines with no real issues -- and, most critically, with
>>> *fewer* issues than on unpatched systems.
>>> Real issues do _occasionally_ occur, but so do bad disks, failed ram, bad
>>> offline updates, etc., etc. Fear over lack of atomicity is letting "it's not
>>> perfect!" get in the way of real world usefulness.
>>> Additionally, these updates aren't _silent_ -- they're logged and there's an
>>> e-mailed report.
>> Well I meant things like:
>> Admin: "OK I will reboot box 'foo'"
>> <reboots box 'foo' that was running an update>
>> *boom*
>> (well actually that case can be "solved" by using systemd-inhibitors
>> ... does it do that?)
> This server is almost never rebooted, and in many years running yum-cron I've
> never had any problem.
> What is the difference between automated update vs. a manual update, in terms
> of potential for problems anyway?

The former is happening silently while you (the admin) knows that an
update is going on in the latter case.

More information about the devel mailing list