Невероятная ошибка Cannot redeclare composerRequire

Фанат

oncle terrible
Команда форума
Парни, вот это реально задачка-неберучка
Я не думаю, что она связана с кодом, а скорее с настройками.
Код:
Cannot redeclare composerRequire000d3ab8899df7d6c65bfb19d78a3d3f() (previously declared in
lib/vendor/composer/autoload_real.php:66) in
lib/vendor/composer/autoload_real.php on line 66
Если бы не коллеги, наблю.дающие то же самое, я бы решил что у меня глюки. Судите сами:
- ошибка возникает не постоянно, а где-то 1 раз на сто запросов
- на серваке развернуто три проекта, и ошибка возникает на каждом
я в принципе не могу понять, как она может появиться - файл вызывается через require_once, а в самом файле выше ффункции идет определение класса ComposerAutoloaderInit, и если файл читается заноГо, то тогда падать должны же на определении класса?!
- ошибка водникает только на резервном сервере, который по идее является копией боевого, где этой ошибки не было никогда

PHP 7.2.34 если что (да-да, все понятно, идет разработка новой версии, старая заморожена, но на ней в данный момент работает бизьнесь)
 
composer update + обновить сам компостер, неплохо было бы глянуть все три проекта, что где и как лежит. Подозреваю, что там что-то с автолоадилкой не так.
 
grep -r "composerRequire000d3ab8899df7d6c65bfb19d78a3d3f"
также на всякий случай cache и всякие temp
ну и да, autoload под лупу, а можно также грепнуть на наличие 2го

может также из-за mount и realpath логика нарушается
 
Еще может быть опкеш. Или сам глючит или как-то связано с деплоем/симлинком и тп
 
Вроде совет Кодекса должен помочь
composer self-update
 
Да, но, чтобы это сделать, как минимум нужно будет удалить composer.lock и vendor, а только потом обновлять.
Иначе ошибку не устранишь, хотя не исключено, что это может быть клон проекта, поставленный на другой каталог.
 
надо смотреть как деплой сделан, какие симлинки, локально ли стоят вендоры, как настроен опкод кеш, в докере или на bare metal, если в докере - настройки кеширования маунтов
если это stage - могли сэкономить на ре-деплое вендоров и контейнеров при сборке

короче, вторая сложная проблема программирования - инвалидация кеша
 
это бой. все три сайта полностью независимы друг от друга.
композера на бою нет
деплой сделан деревянно, все копируется с локальной машины, тупо файлами, без единого симлинка.
одним и тем же скриптом на ансибле, который используется для всех серверов
сейчас склоняемся к опкоду, но блин непонятно в каком месте
 
в общем, один и тот же урл при десятке обновлений выдаёт ошибку
то есть это точно не уровень кода
либо фпм, либо вообще железо
 
zend_mm_heap corrupted

то есть это конечно может быть и не опкеш а любые внутренности, но кроме опкеша в этом контексте некому по большому то счету
 
Задизейблить опкеш и посмотреть что выйдет? =\
 
ну в качестве иксперимента подойдет конечно, но решение-то все равно нужно с опкешью...
ну там одмины уже занимаются, я думаю методом "всё снесу, один останусь"
 
ну в качестве иксперимента подойдет конечно, но решение-то все равно нужно с опкешью...
обновляться и проверять на 8, как всегда - c 7.2 никто разбираться не будет
и рассказать CTO про bill of materials c decomission, а то выучили "time to market", и чиллят с серьезной рожей
 
обновляться и проверять на 8, как всегда - c 7.2 никто разбираться не будет
ну хотя бы на 7.4, это вообще без проблем должно пройти

и рассказать CTO про bill of materials c decomission, а то выучили "time to market", и чиллят с серьезной рожей
😂
 
Сверху