Comments 2
А где собственно сам ранбук для Ansible?
И ещё вопрос. Почему:
где‑то на третьем сервере оно падает, потому что в /var или /boot кончилось место.
если
Старые ядра удаляются через dnf repoquery --installed --installonly с явным исключением загруженного ядра.
Т.е. почему заканчивается место в /boot, если старые ядра удаляются?
Второй вопрос. Зачем расширять место автоматически в /var, если там, как правило, место съедают логи (/var/log) база данных (/var/lib). Может стоит лучше вручную посмотреть, что там за проблема? Если место скушала база, то +10 GB ей не особо помогут. Если место скушали логи, то может быть лучше настроить logrotate или посмотреть, что пишет слишком много логов, возможно, кто-то забыл отключить debug.
Также было бы неплохо использовать мониторинг, типа zabbix, чтобы проблемы с нехваткой места решать заранее, а не когда происходят внезапные работы с сервером.
Про /boot: ядра-то сносятся нормально, дело не в них.
dnf по дефолту держит три ядра (installonly_limit), и лишнее выкидывает только когда ставит новое. А ядро — это не только vmlinuz на 10 метров, к нему ещё initramfs 40–100 (в host-only и жирнее бывает) плюс kdump-образ такого же порядка, если kdump включён. Три ядра с kdump — уже под 700 метров, а /boot по дефолтной разметке 512М–1Г. Впритык изначально.
Плюс пик — ровно в середине транзакции: новое ядро распаковано, dracut initramfs собрал, а старое ещё лежит, оно уедет в конце. То есть в моменте там N+1 ядер, и оно падает именно тогда, а не «потом, когда почистится».
Плюс половина барахла в /boot вообще не принадлежит пакетам, поэтому repoquery его в упор не видит. Дёрни rpm -qf /boot/initramfs-*.img — на что-то скажет not owned by any package. initramfs же генерится скриптлетом уже после установки, в файлах пакета его нет. При штатном сносе ядра он подчищается, а если ядро выпиливали руками, транзакция когда-то отвалилась или машину клонировали — висит сиротой вечно. Плюс initramfs-0-rescue-*, который не удаляется никогда, и после смены machine-id их накапливается по несколько штук по 80 метров. du -sh /boot/* — и обычно сразу видно, что полраздела занято тем, чего в rpmdb нет.
А /var кончается по своей причине, к ядрам вообще отношения не имеет: dnf тянет всю транзакцию в /var/cache/dnf до начала установки, там же rpmdb и history.
Про расширение /var — оно не про логи. Это чтобы обновление не сдохло на середине транзакции с недописанным rpmdb, разгребать такое куда дороже, чем пара лишних гигов на LV. Если место скушала база или забытый debug — да, + память - это только отодвинет, но плейбук её и не должен лечить, его задача довести апдейт до конца и не оставить сервер в разобранном виде.
По zabbix'у согласен на все сто, триггеры нужны, и лучше предиктивные по тренду, а не голый порог.
Но одно другое не заменяет: мониторинг не знает, сколько сожрёт конкретная транзакция, а плейбук не видит тренда между патчингами.
Ansible против нехватки места: как я научил плейбук самостоятельно расширять диски виртуалок и патчить RedOS