nginx+php-fpm - искажает исходный код

Приветствую

Добрый вечер

DISSINCT вместо DISTINCT Ощущение, что где-то кэшируется исходный код и он оказался битым (?), как такое вообще может быть?

RAM bit flip

Подскажите, что это было и как это предотвратить в будущем?

Если сервер реальный - почистить, memtest etc Если виртуальный - напрячь хостера.

У пхп есть возможность кешировать исходный код (opcache), но она не просто есть, а зависит от настроек. По умолчанию в дистрах, думаю, выключена, но вообще сам проверяй. https://www.php.net/opcache_get_status

Чтобы T превратилось в S надо 3 бита изменить, сомнительно.

SIGKILL

Посмотри системные логи на предмет oom, может это он. Если не он - то что-то постороннее в системе могло быть.

И что за хостинг? Свой сервер, виртуалка или шаред?

Не похоже на bit flip. Там бы скорей S превратилась в R

Но проблема таки скорей железная, соглашусь

чтобы T превратилось в S надо 3 бита изменить, сомнительно.

Не похоже на bit flip.

   S         T
01010011 01010100

что не отменяет наличие PoC-ов атак на bit flip. Может, как раз ECC DBE пробивают )

По описанию T -> S

Ну все равно T это 0x54 который хорошо переходит в 0x55, 0x56, 0x500 (T-U, T-V, T->P). Так что тут как-то непонятно. Двухбитовая «ашипка» и память без ECC?

Opcache есть и он включен, но он был и до этого с apache+mod_php, а проблема появилась после переезда на nginx+php-fpm.

В системных логах ничего необычного нет в момент и до возникновения проблемы.

Сервер - виртуалка.

Не знаю. Две ошибки с одним символом выглядят ещё более необычно.

Нашел, в первый раз при такой проблеме был «&» вместо пробела.

Наверно ещё есть?

             &
0010 0000 0010 1100

    T        S     
0101 0100 0101 0011

Других случаев не было.

Получается, что в обоих случаях не меньше двух битов - это не исключает bit flip?)

Ладно, попробую в поддержку хостера написать, хотя предполагаю, что они просто предложат виртуалку перенести, а этого не очень хочется.

Получается, что в обоих случаях не меньше двух битов - это не исключает bit flip?)

Нет.

А php-fpm, nginx и т.д. давно обновлялись?

Может в логах есть «необычные» запросы перед падением?

php-fpm, nginx поставлены в начале года и проблема возникла пару раз с интервалом где-то месяц.

Да все логи просмотрел, ничего необычного. Единственное - в логах php-fpm за 20 секунд до начала проблемы:

WARNING: [pool www] child 22750 exited on signal 9 (SIGKILL) after 1968.575078 seconds from start

Все логи это включая логи ядра?

Сделай grep -i oom /var/log/*.

виртуалку перенести, а этого не очень хочется.

Чего не хочется? Ты не заметишь ничего скорее всего (если у них всё нормально настроено), тебе будет показываться всё та же виртуалка с тем же диском и тем же айпи-адресом.

Другое дело если ты хочешь сначала поисследовать ситуацию.

они просто предложат виртуалку перенести, а этого не очень хочется.

Какие другие идеи «обхода» есть?

Было два разных случая «в кеше»? Что происходило между этими событиями… – раскручивать «это» проще переноса виртуалки?

P.S. Исправил, переработал «иллюстрацию»

          |     T    
0010 0000 | 0101 0100
          |
    &     |     S
0010 0110 | 0101 0011

grep -i oom /var/log/*

ничего не выдает на нужную дату

OOM ни при чем.

это не исключает bit flip

Чувак, это шутка была. Конечно это никакой не bit flip, иначе с таким везением тебе срочно нужно бежать и скупать все лотереи.

А кто ему SIGKILL ещё прислал?

Да кто угодно. И если бы OOM пришел - в логах бы что-то было

«Кто угодно» SIGKILL не рассылает. Из автоматических только oom вспоминается, всё остальное вручную кем-то.

А, ну и ещё хостер мог програмный ребут виртуалки запустить, хотя в этом случае демон скорее всего всё-таки по SIGTERM бы завершился штатно.

На сервере крутятся скрипты довольно затратные по памяти и времени - может ли быть SIGKILL из-за нехватки памяти, к примеру?

Хостер не мог ничего ребутить без предупреждений/уведомлений.

может ли быть SIGKILL из-за нехватки памяти, к примеру?

Может, это oom и есть.

может ли быть SIGKILL из-за нехватки памяти, к примеру?

может. оом=Out Of Memory

но это не объясняет проблему S и &.

На VM RAM может быть куском баллона гипервизора, в т.ч. и физическим диском. Так штаа )

На VM RAM может быть куском баллона гипервизора, в т.ч. и физическим диском. Так штаа )

А ну кстати да, там может быть TLC/QLC SSD и как раз флип на единицу сразу пачки соседних битов. Но по идее у них ECC и они должны такое ловить.

Пришел ответ от поддержки, у них два предположения:

1. One possibility is an IOwait time that causes the OPCache to pass invalid information during load - I do know that some cloud providers do not want OPCache enabled on shared systems because of this.

2. The next most likely culprit would be file system corruption.

Наверно, надо будет сначала попробовать перенести виртуалку, копаться в этом нет желания.

Первое это какое-то враньё. Второе может быть но маловероятно.

Тогда что это?))

Спустя несколько месяцев примерная причина найдена, но как ее решить - до сих пор не знаю.

Итак, если какой-то скрипт выполняется на сервере и в этот момент загрузить его новую версию на сервер, то это приводит к искажению исходного кода абсолютно любого другого скрипта на сервере.

Единственное решение сейчас - после загрузки файла на сервер делать рестарт php-fpm и nginx…