"freebsd-update cron" returns "no mirrors found"

O

obamatronic

I have set up a cron job in /etc/crontab.

It looks something like this:

Code: 
10      10      *       *       *       root    freebsd-update cron -t mymail@example.com

After the random period of time, I receive an email like this:
Code: 
Fetching metadata signature for 9.1-RELEASE from update.FreeBSD.org... failed. 
No mirrors remaining, giving up.

If I manually run
Code: 
freebsd-update fetch
everything runs as normal (no failures).

I can successfully
Code: 
dig update.freebsd.org
(which is the default server pool in /etc/freebsd-update.conf).

Any ideas?
 
update and update2 servers down (?)

Same issue here, but I've been at it a while and note the following:

Manual runs of [CMD=]freebsd-update[/CMD] on my systems return the same "no mirrors found" message. I've tried from three different hosts using two ISPs. The site http://www.downforeveryoneorjustme.com tells me that update.freebsd.org and update2.freebsd.org (the sites returned for update.freebsd.org using dig) both appear to be down.

As it happens, I used the -s option to pull from update3.freebsd.org and upgraded a test server from 8.3 to 9.1, but now that system has some as-yet unexplained load issues...

DNS results from my two ISPs, Google (8.8.8.8), and OpenDNS's servers all point to the same seemingly invalid entries. I suspect the source is out there, but at a different address.

For reference:

Code: 
;; ANSWER SECTION:
update.freebsd.org.     2364    IN      CNAME   update2.freebsd.org.
update2.freebsd.org.    2364    IN      A       149.20.53.21

[ I tried iterating to update3 on a lark. The following information is what I dug up on it ]
Code: 
update3.freebsd.org.    1656    IN      A       147.229.9.40
 
I had that problem a few months ago.
As far as I remember it was a DNS issue. Play around with something like:
Code: 
# dig @[your DNS server] update.freebsd.org
# dig @8.8.8.8 update.freebsd.org
# dig @[your IPS's DNS server] update.freebsd.org

and compare the results - note any differences. Maybe some DNS caching in place on your side?
Or some old entries in /etc/hosts? Check /etc/resolv.conf.

You can shorten your test-cycle by changing your crontab-entry (temporarily) to:
@reboot freebsd-update cron -t mymail@example.com
Click to expand...
and restarting cron with
# /etc/rc.d/cron restart
That way all @reboot-entries will be executed immediately ;)

Watch your status-emails from cron.
 
I found a similar behaviour here in my virtual machine.
Here I think it has to do with (one or more):
- dns/unbound starting later than the first cronjobs?
- Proxies on my way out?
- returned IP-adresses (see DNS above)
- timeouts?

Sometimes a manual call works not, too. Then, five seconds later, the same command succeeds...
 
You must log in or register to reply here.
Back
Top