Re: dnf update vs Software Udpates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Pete,

On Wed, Jul 22, 2015 at 05:42:15PM -0500, Pete Travis wrote:
> 
> There is a timer unit, `/usr/lib/systemd/system/dnf-makecache.timer`, that
> fires ten minutes after each boot then one hour following the execution of
> each previous run.  It triggers
> `/usr/lib/systemd/system/dnf-makecache.service`, a service that executes
> `dnf -v makecache timer`.  When that command runs, dnf will check the age
> of the current metadata cache and refresh it if it is older than the value
> of * metadata_timer_sync* (seconds) in `/etc/dnf/dnf.conf`.

Thank you for this clear and very nice explanation.

> So, an always-on computer should never have metadata older than 4 hours; in
> practical terms, I think values >2 hours are increasingly unlikely.  A
> computer that's been off overnight and turned on in the morning should have
> a fresh cache within 15 minutes of boot.  If you have, say, a laptop that
> you power down often and often install or update packages immediately after
> boot, you might adjust the OnBootSec value by copying dnf-makecache.timer
> to /etc/systemd/system/ and editing accordingly.  Or, consider appending
> --refresh on an as-needed basis.

I think this is where things go wrong.  OnBootSec handles powerdowns,
what about intermittent connections?  In principle, it is quite possible
everytime the timer triggers the makecache service, the connection is
absent.  In fact, the probability to hit the sweet spot is directly
determined by the reliability of the connection.  So a connection that
is up 50% of the time, will miss 50% of the makecache jobs.  Maybe the
makecache jobs can reset the timer to try again in 10 mins in case of no
network connectivity.  I think that would make the odds more favourable.

Essentially I'm suggesting to treat no connectivity as a powercycle.
Hopefully this gives the devs some ideas.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux