В systemd (CentOS8) я заметил dnfпоявление в журналах ( /var/log/messages) даже после того, как я сделал dnf remove dnf-automatic. Я обнаружил работающий таймер ( systemctl list-unit-files --type=timer) для dnf-makecache.timer.
Лучшее, что я смог найти в сети, это то, что dnf-makecache "обновляет кэши репозитория". Хорошо, но что это на самом деле означает? Почему кэши репозитория должны обновляться каждый час? Разве это не произойдет в любом случае, если использовать обновление вручную с помощью dnf update?
Будет ли dnf updateтерпеть неудачу или не получать новейшие версии, если dnf-makecacheне обновлялся? Или это что-то, что дополняет dnf-automaticи не нужно, если не использовать автоматический? ИМХО: если это так, то его следовало удалить, когда dnf-automaticон был удален.
Минусы отключения этого таймера с помощью systemctl disable dnf-makecache.timerи systemctl stop dnf-makecache.timer?
решение1
Хорошо, но что это на самом деле означает?
Это означает, что удаленный индекс пакетов загружается в локальный файловый кэш, чтобы ускорить выполнение последующих dnfкоманд.
Почему кэши репозиториев необходимо обновлять каждый час?
Это сделано для удобства и ускорения dnfкоманды. Каждый раз, когда вы запускаете команду eg dnf install, ей нужны «свежие» метаданные для репозиториев. Без этого высока вероятность того, что придется ждать обновления метаданных при dnfинтерактивном запуске команд.
Обратите внимание, что, несмотря на то, что таймер установлен на каждый час, эффективное время выполнения не чаще, чем каждые 3 часа. Это скорее ошибка, которая подробно описаназдесь.
Разве это не произойдет в любом случае, если использовать обновление вручную с помощью dnf update?
Да, по умолчанию это произошло бы в любом случае.если метаданные считаются устаревшими. То есть, превышено время жизни по умолчанию в 6 часов (определение для каждого репо может переопределить это TTL). Это никогда не произойдет для репо, если его определение имеет metadata_expire=-1.
Будет ли dnf update завершаться ошибкой или не будут ли получены новейшие версии, если dnf-makecache не обновлялся?
Нет, не подведет. Хотя можно сказать, что он мог бы быть немного надежнее, при условии, что метаданные уже есть, а сетевое соединение нестабильно.
Или это что-то, что дополняет dnf-automatic и не нужно, если не используется automatic?
Он дополняет оба варианта dnf, dnf-automaticпоскольку у обоих вариантов больше шансов работать с новым кэшем метаданных, а значит, работать быстрее.
Минусы отключения этого таймера с помощью systemctl disable dnf-makecache.timer и systemctl stop dnf-makecache.timer?
Более медленные dnfкоманды / интерактивное ожидание установки и обновлений. Если вы не продолжите статью и не исправите:
metadata_timer_sync=3600
Таймер совершенно неэффективен и не принесет особой пользы.
P.S. Вы задаете много вопросов, но в этом сообществе обычно стоит задать один :)
Пожалуйста, проконсультируйтесь man dnfи man dnf.conf. Те, кто правит документацию, не должны делать этого напрасно.
решение2
Поскольку мои серверы centos 8.1 находятся за брандмауэром и ограниченным прокси, dnf-makecache-timer постоянно генерирует раздражающие ошибки. Кажется, он использует случайный динамический список серверов, которые я не могу все добавить в доверенный прокси-белый-лист. Это такжепротивнаши правила безопасности.
В yum появилась возможность определить список серверов, которые будут использоваться и учитываться (вероятно) во всех действиях менеджеров пакетов: mirrorlist=… и include_only=… .
Мне не удалось найти работающего решения или настройки для ограничения серверов, используемых таймером dnf-makecache.
Как ни странно, вызов командной строки ни разу не завершился неудачей, когда я пытался это сделать.
Насколько я понимаю, подразумеваемый (в моем нынешнем понимании) законный вопрос(ы):
«Мне это не нужно, я этого не хочу, (в нашем случае) оно выдает ошибки, которые я не могу контролировать: Как мне это отключить?
Я отвечу на него здесь:
Добавить в [main]раздел -/etc/dnf/dnf.conf
metadata_timer_sync=0
как указано на странице руководства dnf.conf:
Use 0 to completely disable automatic metadata synchronizing.