Обновление ядра без перезагрузки

Решил попробовать обновление ядра без перезагрузки от KernelCare.

Установка очень проста (на примере CentOS 6.x):

# rpm -i http://patches.kernelcare.com/kernelcare-latest.x86_64.rpm
# kcarectl --register <youid>

Просмотреть информацию о примененных патчах можно командами:

# kcarectl --info
kpatch-state: patch is applied
kpatch-for: Linux version 2.6.32-042stab111.11 (root@kbuild-rh6-x64.eng.sw.ru) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Tue Sep 1 18:19:12 MSK 2015
kpatch-build-time: Fri Oct  2 10:30:28 2015
kpatch-description: 2;2.6.32-042stab111.12

# kcarectl --patch-info
OS: openvz
kernel: vzkernel-2.6.32-042stab111.11
time: 2015-10-03 07:53:24
uname: 2.6.32-042stab111.12



kpatch-name: 2.6.32/diff-vfs-test-for-and-handle-paths-that-are-unreachable-from-their-mnt_root
kpatch-description: vfs: Test for and handle paths that are unreachable from their mnt_root
kpatch-kernel: >vzkernel-2.6.32-042stab111.11
kpatch-cve: N/A
kpatch-cvss: N/A
kpatch-cve-url: N/A
kpatch-patch-url: N/A

kpatch-name: 2.6.32/kernelcare-openvz-cpt-rst-deadlock-workaround.patch
kpatch-description: 
kpatch-kernel: 
kpatch-cve: 
kpatch-cvss: 
kpatch-cve-url: 
kpatch-patch-url:

К сожалению поддержки комбинации debian7 + openvz нет и не планируется. Две ноды у меня сейчас работают в такой связке. Одну можно переустановить на CentOS 6.x без особых проблем, но вторую будет значительно сложнее.

Вначале меня смутило сообщение

# kcarectl --info
Unknown kernel (CentOS 2.6.32-042stab111.12), no patches available

но в случае с поддерживаемой системой это означает, что нет доступных обновлений.

Vzctl 4.9.4-1 на Debian нодах нарушает работу контейнеров с ploop layout

После обновления vzctl до 4.9.4-1 на нодах с Debian Wheezy перестала нормально работать часть контейнеров с ploop layout. У меня обошлось минимальным ущербом - просто не сработал ночной бэкап одного из серверов, т.к. не смогло создать снапшоты контейнеров с ploop. Разбор полетов выглядит так:

% sudo vzctl snapshot-list 1068
Snapshot feature is only available for ploop-based CTs

% sudo tail /etc/vz/conf/1068.conf

# Upgrade Thu Sep 10 12:01:51 MSK 2015: Securing CT config by adding VE_LAYOUT=simfs
VE_LAYOUT=simfs

% sudo ls -ld /var/lib/vz/private/1068/root.hdd 
drwx------ 2 root root 4096 Aug 18 09:03 /var/lib/vz/private/1068/root.hdd

% sudo vzlist -o ctid,layout 1068
      CTID LAYOUT
      1068 simfs

При этом произошло это тихо и незаметно, а при перезагрузке такого контейнера или ноды, с высокой долей вероятности он бы превратился в тыкву.

Для исправления достаточно исправить значение VE_LAYOUT в конфигурации нужных контейнеров.

UPDATE: Зарепортил проблему: OVZ-6531.

500 OOPS: prctl PR_SET_SECCOMP failed

После рестарта openvz ноды в контейнерах vsftpd начал ругаться "500 OOPS: prctl PR_SET_SECCOMP failed", чтобы решить проблему в лоб достаточно добавить в vsftpd.conf параметр "seccomp_sandbox=NO" и перезапустить vsftpd.

# echo 'seccomp_sandbox=NO' >> /etc/vsftpd.conf
# service vsftpd restart

Позже гляну связано ли это с апгрейдом openvz ядра с 2.6.32-042stab106.6 на 2.6.32-042stab108.2.

Не обновляйте ploop на 1.13-1

Сегодня выловил регрессию в работе ploop 1.13-1. Если у запущенного контейнера создать снапшот, а потом попробовать его удалить, то ничего не выйдет:

# vzctl snapshot-delete 1101 --id 9c585491-c98b-42a5-8002-2387eee11aa1
Deleting snapshot {9c585491-c98b-42a5-8002-2387eee11aa1}
Storing /vz/private/1101/Snapshots.xml.tmp
Error in check_snapshot_mount (ploop.c:3722): Snapshot {5fbaabe3-6958-40ff-92a7-860e329aab41} is busy by device(s): /dev/ploop17343 
Failed to delete snapshot: Error in check_snapshot_mount (ploop.c:3722): Snapshot {5fbaabe3-6958-40ff-92a7-860e329aab41} is busy by device(s): /dev/ploop17343  [17]
Failed to delete snapshot {9c585491-c98b-42a5-8002-2387eee11aa1}

Версия ploop:

# rpm -qa \*ploop\*
ploop-lib-1.13-1.x86_64
ploop-1.13-1.x86_64

Если контейнер предварительно остановить, то снапшот удалится. Похоже это связано с неудачным фиксом #2887. Для решения проблемы достаточно откатиться на ploop 1.12.2:

# wget http://download.openvz.org/current/prev/ploop-1.12.2-1.x86_64.rpm http://download.openvz.org/current/prev/ploop-lib-1.12.2-1.x86_64.rpm
# yum downgrade ploop*1.12.2*.rpm

UPDATE: Запостил баг.

Удаление systemd в Debian Jessie/Sid

В одном из контейнеров OpenVZ, недавно обновленном до Jessie, начались проблемы со временем захода в контейнер по SSH. Почитал логи и нашел:

$ egrep 'time.*out' /var/log/auth.log
Apr  1 09:49:27 debian8 sshd[16956]: pam_systemd(sshd:session): Failed to create session: Connection timed out
Apr  1 10:46:52 debian8 sshd[16986]: pam_systemd(sshd:session): Failed to create session: Connection timed out
Apr  1 10:46:52 debian8 systemd-logind[172]: Failed to start user service: Connection timed out
Apr  1 10:47:17 debian8 systemd-logind[172]: Failed to start session scope session-10.scope: Connection timed out (null)
Apr  1 11:03:19 debian8 sshd[16998]: pam_systemd(sshd:session): Failed to create session: Connection timed out
Apr  1 11:50:56 debian8 sshd[17019]: pam_systemd(sshd:session): Failed to create session: Connection timed out
Apr  1 11:51:13 debian8 sshd[17024]: pam_systemd(sshd:session): Failed to create session: Connection timed out

Началось после suspend'а контейнера. Скорее всего какая-то нестыковка OpenVZ и systemd, но разбираться в этих нюансах нету времени.

Тут нашлась инструкцию по удалению systemd из Jessie/Sid. На всякий случай задублирую ее себе:

Установить SysV init

$ sudo aptitude install --without-recommends sysvinit-core sysvinit sysvinit-utils

Теперь важно сначала перезагрузить систему, чтобы инициализация прошла через SysV init. Затем удалить пакет systemd и запретить его установку в будущем

$ sudo aptitude purge systemd
$ echo -e 'Package: systemd\nPin: origin ""\nPin-Priority: -1' | sudo tee /etc/apt/preferences.d/no-systemd

После удаления systemd контейнер пришел в норму.

UPDATE: Если попытаться удалить systemd из десктопной инсталляции, то по зависимостям предложит удалить много чего. Чтобы избежать этого нужно установить пакет sysvinit-core и перезагрузиться.

$ sudo apt-get install sysvinit-core
$ sudo reboot

Будьте внимательны при обновлении vzctl до версии 4.7

Если вы используете OpenVZ и решили обновить сервер, то не пропустите важное сообщение при обновлении vzctl до версии 4.7.

============================================================================
Due to conntrack impact on venet performance, conntrack need to be disabled
on the host system (it will still work for containers).

Adding the following option to /etc/modprobe.d/openvz.conf:

      options nf_conntrack ip_conntrack_disable_ve0=1

This change will take effect only after the next reboot.

NOTE: IF YOU NEED conntrack functionality, edit /etc/modprobe.d/openvz.conf NOW,
changing =1 to =0. DO NOT REMOVE the line, or it will be re-added!
============================================================================

Начиная с этой версии по-умолчанию отключается conntrack в VE0 (на hardware node). Если ваш файервол полагается на conntrack, то вы рискуете закрыть всем (и себе тоже) доступ на Hardware Node по сети.

Привязка контейнера OpenVZ к определенным ядрам процессора в Debian Squeeze

Поскольку в debian squeeze утилита vzctl довольно лохматой версии и не поддерживает опцию --cpumask, то пришлось городить велосипед, чтобы прикрепить конкретный контейнер на выделенные ядра процессора.

У подопытного сервера 4 ядра с hyper-threading - итого система видит 8 ядер. Перемещаем все процессы системы, для которых еще не задан явно affinity на ядра 4,5

for _PID in `ps --no-headers -A -o pid`
do
    taskset -p -c $_PID 2>/dev/null | grep -q 0-7$ && taskset -p -c 4,5 $_PID
done

Контейнер с VEID 300 на ядра 0-3

ps --no-headers -A -o pid | xargs vzpid | tail -n+2 | awk '{if ($2 == 300) print $1}' | xargs -n 1 taskset -p -c 0-3

Посмотреть все привязки в системе можно так:

ps --no-headers -A -o pid | xargs -I {} taskset -p -c {} 2>/dev/null

Ошибка обновления vzctl на RHEL/CentOS 5.x - решение

После выхода vzctl-4.0 появилась проблема с обновлением vzctl на RHEL/CentOS 5.x. Ошибка выглядит примерно так

# yum upgrade vzctl
Loaded plugins: dellsysid, fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.fdcservers.net
 * centosplus: mirror.beyondhosting.net
 * extras: mirror.sanctuaryhost.com
 * openvz-kernel-rhel5: mirror.fdcservers.net
 * openvz-utils: mirror.fdcservers.net
 * updates: mirror.wiredtree.com
Setting up Upgrade Process
Resolving Dependencies
--> Running transaction check
---> Package vzctl.x86_64 0:4.0-1 set to be updated
--> Processing Dependency: vzctl-core = 4.0-1 for package: vzctl
--> Processing Dependency: vzquota >= 3.1 for package: vzctl
--> Processing Dependency: libcgroup.so.1()(64bit) for package: vzctl
--> Processing Dependency: libvzctl-4.0.so()(64bit) for package: vzctl
--> Running transaction check
---> Package libcgroup.x86_64 0:0.38-1 set to be updated
---> Package vzctl-core.x86_64 0:4.0-1 set to be updated
---> Package vzquota.x86_64 0:3.1-1 set to be updated
--> Processing Conflict: vzctl conflicts ploop-lib < 1.5-1
--> Restarting Dependency Resolution with new changes.
--> Running transaction check
--> Processing Dependency: ploop-lib = 1.4 for package: ploop
---> Package ploop-lib.x86_64 0:1.5-1 set to be updated
--> Running transaction check
---> Package ploop.x86_64 0:1.5-1 set to be updated
--> Processing Conflict: ploop-lib conflicts vzkernel < 2.6.32-042stab061.1
--> Finished Dependency Resolution
ploop-lib-1.5-1.x86_64 from openvz-utils has depsolving problems
  --> ploop-lib conflicts with ovzkernel
Error: ploop-lib conflicts with ovzkernel
 You could try using --skip-broken to work around the problem
 You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest

Вчера в блоге OpenVZ нашлось решение этой проблемы. Если кратко то решение выглядит так:

# yum shell
> remove ploop ploop-lib
> update vzctl
> run

Поскольку поддержка ploop есть только в ядрах для RHEL/CentOS 6.x, то ploop можно смело удалить в RHEL/CentOS 5.x.

Новые версии vzctl и ploop

Сегодня пришло письмо от крона, который проверяет доступность обновлений на серверах работающих с легковесной виртуализацией OpenVZ. На продакшен серверах я предпочитаю не полагаться на автоматическое обновление и поэтому установка обновлений производится вручную.

Обычно проверив список обовляемых пакетов я топаю на сервер и выполняю там

# yum upgrade

Но сегодня видимо особый день и привычный процесс отвалился с множеством ошибок и конфликтов зависимостей. В списке конфликтов были vzctl и ploop, которым не понравилась версия ядра vzkernel (установлено последнее доступное openvz-ядро для CentOS 5).

Ответ нашелся в списке новостей на сайте openvz. Оказалось, что вчера вышли новые версии vzctl и ploop и для работы последнего нужно работающее ядро vzkernel >= 2.6.32-042stab061.1. Причем нет возможности отдельно обновить vzctl поскольку ему нужен свежий ploop.

Чтобы попытки обновить vzctl и ploop не мешали установке других апдейтов, пришлось отключить секцию openvz-utils в yum (еще можно добавить их в exclude в /etc/yum.conf, но мне проще вырубить всю ветку).

Из приятных новостей - в vzctl добавили возможность работать на относительно свежих немодифицированных ядрах. При этом пока такая поддержка объявлена экспериментальной и похоже ничего кроме как запустить контейнер у вас не получится (сейчас даже штатное выключение контейнера не работает). Полный список фич: vzctl-4.0, ploop-1.5

В процессе прочтения новостей, наткнулся на видео, где показывают разницу между online и offline миграцией в openvz.

Повреждение FS на ядре под openvz

Поднял новый сервер под ALTLinux Server 4.0.1 (x86_64). Получился вполне приличный тазик, хоть и на десктопном железе:

CPU: AMD Phenom II X4 955
RAM: 8Gb DDR3
MB:  ASUS M4A77TD PRO
HDD: 4xSATA2 WDC WD2502ABYS

Не обошлось без ложки дегтя, гигабитная сетевушка побила файлы при передаче (не сошлась md5) - воткнул завалящийся realtek 8139. Для видео выбрал S3 Trio (это который PCI с одним метром оперативы =) ) На ночь поставил переноситься данные со старого сервера.
С утреца ждал неприятный сюрприз, рассыпались почти все файловые системы и процесс копирования данных накрылся медным тазом. После общения с альтовской багзилой и гуглежом, оказалось что я использую языческое ядро (2.6.18-ovz-smp-alt14 и 2.6.18-ovz-smp-alt26.M40.2 - пробовал оба) и мне следует срочно обратиться к использованию сборки с патчами от redhat (2.6.18-ovz-rhel-alt2.M40.4).
Хотя странно, как тогда глючное ядро вообще могло попасть серверный дистрибутив. Насчет изначальной глючности openvz ядер - верить отказываюсь, т.к. имею опыт с дебиановскими ядрами работа которых проблем не вызывает. К альту у меня вообще много претензий последнее время, начиная их недо-инсталятором. (последний раз ставил через графический режим, так вот дойдя в сетевых настройках до многострочного поля ввода (search domains) оттуда нельзя выбраться табом)

P.S. После смены ядра аптайм перевалил за 20 дней - полет нормальный.

ASUS M4A77TD PRO

Вчера наткнулся на ошибки при работе нового сервера.

APIC error on CPU0 40(40) - появляется под нагрузкой и может доходить до 300 штук за пол-часа. Помогло обновление ядра до 2.6.27-ovz и установка в BIOS "PNP OS installed - Yes".
После обновление ядра вылезла проблема с hwclock. hwclock --systohc --utc говорил, что /dev/rtc не найден, вместо него есть /dev/rtc0. После hwclock --rtc=/dev/rtc0 --systohc --utc часы обновились нормально.