You are not logged in.
so - isn'T a LIST meant to be used as "ok, when one doesn't work try the next?"
currently my list is rather small, created by reflector back in march
today I encountered the top most mirror not working - but instead of falling back to the second mirror and using it pacman just bails with
core ist aktuell
extra ist aktuell
multilib ist aktuell
Fehler: Konnte Datei 'core.db' nicht von berlin.mirror.pkgbuild.com übertragen : Connection timed out after 10002 milliseconds
Fehler: Konnte Datei 'extra.db' nicht von berlin.mirror.pkgbuild.com übertragen : Connection timed out after 10002 milliseconds
Fehler: Konnte Datei 'multilib.db' nicht von berlin.mirror.pkgbuild.com übertragen : Connection timed out after 10002 milliseconds
Warnung: zu viele Fehlermeldungen von berlin.mirror.pkgbuild.com, überspringe den Rest des Vorgangs
(sorry for the german)
isn'T pacman supposed to just use the next mirror in line? why does it fail with that message instead of just "ok, couldn't use that mirror - using next one"?
or do I miss something?
Offline
This looks weird, the databses are deemed up-to-date and then the download of the databases (why does that happen?) times out??
Can you repeat this at will and run "pacman --verbose --debug" on it?
Offline
pacman has gone onto the next mirror and found the files to be up-to-date. All errors for downloads are printed at the end of the downloading (not sure of a better way when doing parallel downloads).
Offline
Success. Uncritical problem summary:
================================
error: your mirror sucks
error: your mirror sucks badly
error: your mirror sucks big time
warning: skipped sucking mirror
Last edited by seth (2025-10-10 21:54:09)
Offline
And to answer the question from the title: there is none. I can’t even recall if it has ever been suggested to have many.
Unless it encounters a failure, pacman uses one and only mirror. It only skips to the next one upon encountering an error. Contrary to what some believe, it does not use them in parallel, in a round robin style, or the most up-to-date one.
There is only a handful of situations, where skipping to the next mirror works reliably. They may be summed up as: the mirror is completely unusable. In other cases, which is most of what users encounter, it’s a transient malfunction. The outcome of which is not a nice fall-back behavior, but a deluge of HTTP errors.
So in my opinion there is no point in having more than one mirror enabled in normal circumstances. If there is any error, you need to address it anyway. It’s better to get a single error, instead of a sea of them. Regardless of my private opinion, there is no technical reason to have more than a few.
The “not normal circumstances” can be e.g. your own caching mirror being placed first, where you know that it either is on and working, or completely off. If it’s off, you want pacman to skip to “global” mirrors.
Last edited by mpan (2025-10-10 22:54:44)
Paperclips in avatars?
NIST on password policies (PDF) — see §3.1.1.2
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
it does not use them in parallel, in a round robin style, or the most up-to-date one
Also see discussion/comments in https://gitlab.archlinux.org/pacman/pacman/-/issues/273 and https://gitlab.archlinux.org/pacman/pacman/-/issues/229
The outcome of which is not a nice fall-back behavior, but a deluge of HTTP errors.
I've not seen this very often (transient mirror failure) but each time pacman moved on and since the mirrors were apparently sufficiently sync'd, actually just went through?
No 404s and while the assumption that this is guaranteed to increase performance is perhaps too bold, so seems the one that this will systematically not work at all?
Offline
and while the assumption that this is guaranteed to increase performance is perhaps too bold, so seems the one that this will systematically not work at all?
But one assumption requires me to do no work!
Offline
pacman has gone onto the next mirror and found the files to be up-to-date. All errors for downloads are printed at the end of the downloading
so - what happended was:
- try download repo-db from first mirror - failed
- silent failover to the next mirror
- try download repo-db from next mirror - success
- print out: repo-db successfully checked to already be up-to-date, but btw mirror X [, y [, ...]] has failed
well ok - thank you for that explanation - and now that I know about it I can live with it - but it was the first time I encountered such a silent failover
is there a reason why it was done this way?
I would expect the failure be written to stderr before the failover so it becomes a not silent one ... as otherwise if its a silent failover why bother to tell me it happened anyway?
Offline
But one assumption requires me to do no work!
Luckily that would be the assumption that the present implementation is sufficiently robust to allow sane fall-throughs on a push but the mirror synchronicity not reliable enough to push it too much.
Formatting the tailing error summary w/ a header indication that this is just fyibtw might still be helpful to reduce the jumpscare… and is less effort than, say, finishing a book
Offline