502 ошибка после обновления Tickets после 1.7.0
После выпуска в репозитории пакета Tickets 1.7.0 легко обновил на всех сайтах кроме одного, самого крупного.
После обновления на фронте ошибка 502 Bad Gateway.
С тех пор уже версия 1.7.4-pl с критическими обновлениями безопасности — а обновиться никак не получается — уже несколько раз пробовал по разному!
Помогите пожалуйста обновиться!
В процессе обновления пакета ошибок не было никаких.
Переустановка пакета ничего не даёт.
Стоит последний MODX Revolution 2.5.2-pl, PHP 7, modhost.pro.
В поддержке хостинга сказали, цитирую:
В логах ошибки:
И это именно из-за нового Tickets! Откатываю старый — работает нормально, только устанавливаю новый — весь сайт отваливается.
После обновления на фронте ошибка 502 Bad Gateway.
С тех пор уже версия 1.7.4-pl с критическими обновлениями безопасности — а обновиться никак не получается — уже несколько раз пробовал по разному!
Помогите пожалуйста обновиться!
В процессе обновления пакета ошибок не было никаких.
Переустановка пакета ничего не даёт.
Стоит последний MODX Revolution 2.5.2-pl, PHP 7, modhost.pro.
В поддержке хостинга сказали, цитирую:
Каким образом это всё касается поддержки хостинга?
modx.pro работает на 1.7 с самого первого дня её выпуска, летом — проблем нет.
В логах ошибки:
2016/11/21 22:48:49 [error] 24341#24341: *1836538 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: ***.***.3.131, server: s***.h*.modhost.pro, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:11924", host: "******.com", referrer: "https://*******.com/manager/?"
И это именно из-за нового Tickets! Откатываю старый — работает нормально, только устанавливаю новый — весь сайт отваливается.
Поблагодарить автора
Отправить деньги
Комментарии: 13
Скрипты из консоли запускал как тут описано modx.pro/components/9412-tickets-1-7-0-ratings-improve-and-accelerate-the-work/
Первый выдал такой результат:
Первый выдал такой результат:
~/www/core/components/tickets/cron$ php remove_votes.php
Done in 0 sec.
а второй такой:~/www/core/components/tickets/cron$ php rebuild_rating.php
Segmentation fault (core dumped)
Не знаю, это правильно или нет, но сработали они моментально, без ожидания.
А Системная настройка cache_db, в разделе Кеширование стоит в Да(Yes)?
На одном из сайтов после обновления 1.7 и заходе в любой раздел Тикета сайт уходил в 500-ю из-за настройки кеширования.
На одном из сайтов после обновления 1.7 и заходе в любой раздел Тикета сайт уходил в 500-ю из-за настройки кеширования.
дичь какая-то) отключаю ее — сайт поднимается, включаю — опять ложится…
Ага, то же самое!
— Интересно, на что влияет эта настройка?
— Зачем нужно кэширование базы данных и почему новый Тикетс не работает с ней?
На всех других сайтах эта настройка по дефолту отключена, видно я когда-то что-то пытался наоптимизировать…
Но главное что проблема решена!
— Интересно, на что влияет эта настройка?
— Зачем нужно кэширование базы данных и почему новый Тикетс не работает с ней?
На всех других сайтах эта настройка по дефолту отключена, видно я когда-то что-то пытался наоптимизировать…
Но главное что проблема решена!
Aleksey, спасибо тебе большое!
Похоже сработало!!!
Всё прекрасно работает с отключённой настройкой cache_db.
Вопрос закрыт, надеюсь кому-нибудь твой совет ещё пригодится.
Похоже сработало!!!
Всё прекрасно работает с отключённой настройкой cache_db.
Вопрос закрыт, надеюсь кому-нибудь твой совет ещё пригодится.
Василий) По поводу не сработавших скриптов из консоли — я отключил настройку, выполнид все скрипты (все нормально сработало) и включил настройку снова — пока вроде работает
Круто! Спасибо за рецепт, и у меня он сработал!
Вот только не знаю уже, а стоит ли включать обратно настройку cache_db…
Вот только не знаю уже, а стоит ли включать обратно настройку cache_db…
Там же написано для чего она:
И по умолчанию она выключена.
Если включено, объекты и наборы результатов выборки по SQL запросам кэшируются, значительно снижая нагрузку на базу.
И по умолчанию она выключена.
Да, я и вернул её в значение по умолчанию, от греха подальше. Часто лишняя оптимизация добавляет проблем, достаточно вспомнить глюки AjaxManager )).
Не думаю что на modhost нужна эта настройка…
Не думаю что на modhost нужна эта настройка…
Не думаю что на modhost нужна эта настройка…Она как раз таки на modhost и нужна. Это же не VPS/VDS.
Не уверен, если бы была нужна, то Василий бы позаботился об этой включённой настройке сразу при установке нового сайта, чего не происходит.
P.S. В последнее время у меня сайт раз в несколько дней разбухал с 1 гига разбухал до 8 гигов и начинал глючить от нехватки места — подозреваю это как раз из-за кэширования базы…
P.S. В последнее время у меня сайт раз в несколько дней разбухал с 1 гига разбухал до 8 гигов и начинал глючить от нехватки места — подозреваю это как раз из-за кэширования базы…
Никогда не меняю стандартные настройки кэширования MODX и никому не советую.
Спасибо за решение проблемы с тикетами.
cache_db помогла.
cache_db помогла.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.