Обновление SLES 15.1 до 15.2 приводит к сбою Varnish

Совсем недавно я запустил обновление онлайн-миграции через YaST на SUSE Linux Enterprise Server (SLES) 15.1–15.2, и после этого у меня были следующие их версии:

SLES 15.2
Apache 2.4.43
MariaDB 10.4.17
PHP 7.4.6
Varnish 6.2.1

Моя основная архитектура Linux теперь выглядит следующим образом:

введите описание изображения здесь

Предварительные тесты не выявили конфликтов или проблем до обновления, и он перезагрузился и работал нормально, когда все было завершено. После проверки всего этого я заметил, что varnish.service (varnishd) не запустился. У меня никогда не было проблемы с запуском Varnish, будь то SUSE Linux, CentOS, Ubuntu и т. Д. Я думал, что сначала мой собственный файл vcl вызывал проблемы, поэтому я выбрал файл конфигурации по умолчанию, с которым он идет (/ etc /varnish/vcl.conf) просто чтобы начать с основ, но безрезультатно. Произошла точно такая же проблема.

Тогда я решил сделать снимок и скомпилировать Varnish из исходников. С помощью YaST я удалил пакет varnish и все его файлы конфигурации и службы, а затем загрузил последний файл архива TAR (varnish-6.6.0.tgz) прямо из https://varnish-cache.org/. По иронии судьбы после компиляции и создания Varnish таким образом, та же проблема возникает, когда я пытаюсь запустить Varnish.

Как и в случае скомпилированного (v6.6.0) или сервисного пакета (v6.2.1), я получаю следующие ошибки, точно такие же между ними:

Снимок экрана 1 с лаком

Снимок экрана 2 с лаком

В нем описывается Дочерний объект, не отвечающий на интерфейс командной строки, его уничтожение, а затем упоминается ошибка связи интерфейса командной строки (hdr). И, наконец, сигнал о смерти ребенка = 6.

Что больше всего озадачивает, так это то, что при любом способе настройки Varnish он не работает одинаково. Я полагаю, это будет означать, что проблема не в Varnish как таковом, а в конфигурации сервера? Я просмотрел все форумы по Varnish, которые мог найти, и не нашел ничего более специфичного. Я даже попытался запустить его, попробовав разные параметры CLI (например, настройки тайм-аута, задержки пула и т. Д.), Но он все равно этого не сделает. Опять же, это связано с тем, что загружен самый простой / стандартный файл конфигурации и ничего больше.

# Marker to tell the VCL compiler that this VCL has been adapted to the
# new 4.0 format.
vcl 4.0;

# Default backend definition. Set this to point to your content server.
backend default {
    .host = "127.0.0.1";
    .port = "80";
}

А теперь самое главное ... Я взял еще один сервер (разработка), очистил его и установил SLES 15.2 с нуля, и все, включая Varnish, работает! Так что что-то с обновлением на месте каким-то образом останавливает Varnish. Однако я не могу взять основной (производственный) сервер SLES 15.2 и начать с него таким же образом из-за множества других вещей, которые в настоящее время установлены и настроены на нем.

Я пытаюсь восстановить Varnish и запустить его в текущей обновленной среде, но, похоже, ничего не работает. Кроме того, в журналах Varnish (/var/log/varnish/varnish.log) нет ничего, что могло бы дать мне какую-либо подсказку.

Я не понимаю, что попробовать и куда идти дальше. Я даже попытался запустить Varnish в режиме отладки (-d), а затем попытался заставить ребенка начать таким образом, и это та же самая ошибка.

введите описание изображения здесь

И, в конце концов, я не могу проверить наличие паники, потому что Varnish вообще не запускается.

введите описание изображения здесь

Итак, напомним, буквально все, что я сделал, это запустил обновление на месте с SLES 15.1 до 15.2, перезагрузился, когда все было сделано, и теперь все остальные службы запускаются нормально, за исключением Varnish (который отлично работал на 15.1).


ОБНОВЛЕНИЕ №1: я попытался запустить лак без файла vcl и без серверной части (varnishd -b none), но возникла ошибка. Затем я просто заменил none на localhost и снова вернулся к той же ошибке, что и раньше.

введите описание изображения здесь


ОБНОВЛЕНИЕ № 2: Вот результат выполнения команды strace -f varnishd.

StraceOutput.txt


person Bennito    schedule 18.05.2021    source источник
comment
Я попытаюсь понять это за вас, но вы в основном запускаете assert() в коде. Это строка, запускаемая вашей установкой: github.com/varnishcache/varnish-cache/blob/6.6/bin/varnishd/mgt/. Я поговорю с разработчиками Varnish и посмотрю, что они думают.   -  person Thijs Feryn    schedule 19.05.2021
comment
Это просто выстрел в темноте, но вы в конечном итоге установили и активировали AppArmor в неисправной системе, которая может запретить доступ к какому-то необходимому компоненту?   -  person CupRacer    schedule 22.05.2021
comment
Вы можете использовать strace -f varnishd ...., чтобы проверить, показывает ли это, где существует процесс. Если у вас возникли проблемы с пониманием вывода strace, вы можете просто опубликовать его здесь, и мы могли бы посмотреть.   -  person CupRacer    schedule 22.05.2021


Ответы (2)


Петля VCL

Это долгий путь, но не могли бы вы изменить свойство .port в вашем бэкэнде на 8080 вместо 80? Просто для тестирования.

Потому что, если вы запустите varnishd без явного -a, стандартным портом прослушивания будет 80. Но поскольку ваш файл VCL уже подключается к порту 80 на localhost для своего бэкэнда, вы можете зациклиться.

Я не говорю, что assert(), который запускается в вашей системе, вызван этим, но попытаться стоит.

В более старых версиях Varnish стандартный порт был 6081, но в последних версиях он изменился.

В чем я уверен, так это в том, что ошибка вызвана недоступным файловым дескриптором. Возможно, дескриптор файла, который уже был закрыт.

Пожалуйста, попробуйте и дайте мне знать.

Режим отладки

Также можно включить режим отладки, добавив параметр времени выполнения -d в вашу команду varnishd.

Пожалуйста, попробуйте увеличить подробность вывода отладки

Проверка паники

Еще вы можете выполнить следующую команду, чтобы проверить, не возникла ли паника:

varnishdadm panic.show

Пробуем различные варианты исполнения

Видимо ошибка связана с тем, что он не может загрузить файл VCL.

Давайте попробуем запустить varnishd без файла VCL, чтобы понять, проблема в этом или нет.

Просто попробуйте запустить varnishd с помощью следующей команды:

varnishd -b none

Эта команда запустит Varnish без файла VCL и без серверной части. Когда вы затем попытаетесь получить доступ к Varnish через HTTP, вы должны получить HTTP 503 ошибку. Это не идеально, но, по крайней мере, мы знаем, что Varnish способен не давать сбоев все время.

  • Как только это сработает, вы можете удалить -b и добавить параметр -f, который относится к файлу VCL.
  • Если это тоже работает, попробуйте поиграть с настройкой -s.
  • И так далее ..

Использовать пакеты

Помимо этого, единственный совет, который я могу вам дать, - это установить Varnish с помощью официальных пакетов на поддерживаемой операционной системе. система (Debian, Ubuntu, Fedora, CentOS, RHEL).

person Thijs Feryn    schedule 19.05.2021
comment
Спасибо за совет, но, к сожалению, это тоже не сработало. Я попытался изменить его в vcl.conf на 8080, и у меня такая же проблема. Затем я попытался добавить его прямо в CLI (-a 127.0.0.1:8080), но проблема не исчезла. - person Bennito; 19.05.2021
comment
@Bennito Я обновил свой ответ, добавив некоторую информацию о режиме отладки и панике. Дайте мне знать, если вы попробуете дать мне более подробный вывод. - person Thijs Feryn; 19.05.2021
comment
Проверьте мой обновленный исходный пост об использовании режима отладки / проверки паники. Я уже пробовал их, но забыл добавить. - person Bennito; 19.05.2021
comment
Я добавил дополнительную информацию в раздел Пробуем различные варианты исполнения. По сути, попробуйте сначала запустить varnishd -b none, чтобы увидеть, работает ли это. Мы возьмем это оттуда. - person Thijs Feryn; 20.05.2021
comment
Смотрите обновления №1 и №2. - person Bennito; 24.05.2021
comment
Strace и вывод varnishd -b localhost ясно доказывают, что нет ничего плохого в вашей конфигурации VCL или в свойствах файловой системы соответствующего файла VCL. Проблемы возникают в самой varnishd установке. Я попробую попросить кого-нибудь взглянуть на это, но я не могу предложить никаких гарантий. Мой совет, который вы вряд ли захотите услышать: установите его с помощью пакетов в Debian, Ubuntu или CentOS. - person Thijs Feryn; 25.05.2021
comment
Поменять O / S - это то, что я не могу сделать. Это один из основных производственных серверов в центре обработки данных, где я работаю над инженерными сетями. Опять же, Varnish загружался и отлично работал с SLES 15.1 и 15.2, также отлично работает, если он установлен с нуля, но я не могу этого сделать из-за всего остального, что размещено на этом сервере. Было бы серьезным делом начать все заново, просто чтобы заставить Varnish работать. - person Bennito; 25.05.2021

Проверяя вывод запрошенной команды strace, я обнаружил следующее:

[pid  1129] mkdir("vcl_boot.1621874391.008263", 0755) = 0
[pid  1129] chown("vcl_boot.1621874391.008263", 465, 463) = 0
[pid  1129] setresuid(-1, 465, -1)      = 0
[pid  1129] openat(AT_FDCWD, "vcl_boot.1621874391.008263/vgc.c", O_WRONLY|O_CREAT|O_TRUNC, 0640) = 5
[pid  1129] fchown(5, 0, 0)             = -1 EPERM (Operation not permitted)
[pid  1129] geteuid()                   = 465
[pid  1129] close(5)                    = 0
[pid  1129] openat(AT_FDCWD, "vcl_boot.1621874391.008263/vgc.so", O_WRONLY|O_CREAT|O_TRUNC, 0640) = 5
[pid  1129] fchown(5, 0, 0)             = -1 EPERM (Operation not permitted)

Varnishd пытается изменить владельца как минимум двух файлов, но ему это не разрешено. Я не уверен в деталях, но в качестве следующего шага вы можете попытаться найти эти файлы (возможно, ниже / var / cache / varnish) и проверить текущие разрешения. Возможно, они принадлежат пользователю, который не является пользователем, с которым вы запускаете varnishd.

AFAIK демон запускается от имени пользователя root, а затем процесс переключается на непривилегированного пользователя. Это предположение возвращает нас к моему предыдущему вопросу: используете ли вы AppArmor или SElinux?

person CupRacer    schedule 05.06.2021
comment
AppArmor установлен на сервере. Я могу остановить службу с помощью rcapparmor stop, но Varnish все равно не запустится даже после того, как я остановлю его. Я проверил, есть ли там файлы vgc.c / vgc.so и их разрешения (их не было). Мне удалось найти vgc.so только на моем сервере разработки. Я скопировал его в Production, установил нужные разрешения, и даже после этого Varnish не запускается. Интересно, что в разделе «Разработка» в / var / cache / varnish есть папки _.vsm_child и _.vsm_mgt, но когда я вручную создаю эти папки, они исчезают, когда я пытаюсь запустить Varnish. - person Bennito; 09.06.2021