Попробуйте не указывать src: ip route add xxx.xxx.xxx.63 dev ens23 table wan-63
Но всё равно сомнительно, что broadcast-адрес куда-то удастся прислюнявить.
Ещё в логах можно высматривать, что говорит MySQL, может какие-то отдельные таблицы сбойные?
Тогда можно удалить+залить только сбойные таблицы, вдруг и запустится в обычном режиме.
Копия битой базы хранится?
Самое простое: после полного MySQL-дампа удалить базу, переключить в нормальный режим, и залить полный MySQL-дамп. Так вы получите работоспособную базу в обычном режиме.
НО, большое НО! Останется вопрос в корректности данных в базе. Ведь где-то в таблицах могут хранится значения, которые не соответствуют значеням в других таблицах... И тут уже нужна полная проверка от производителя (Битрикс-а).
Так проверьте, не работает-ли mysql после первого запуска. Вполне возможно он там таблицы восстанавливает, файлы копирует-прочесывает, вот-вот все будет сделано, а вы его пытаетесь перезапустить в этот момент...
Да, судя по всему - физически побились файлы базы данных.
Делайте backup директории /var/lib/mysql (или где у вас хранится вся база), а потом добавляйте параметр "innodb_force_recovery=6" в файл my.cnf, и пытайтесь еще раз стартануть сервис, стандартным путем. Возожно он сам справится с восстановлеием файлов... Если нет - вы же делали ежедневные/еженедельные бэкапы?
Мда, из подробностей только mysqld.service: control process exited, code=exi ted status=1.
Для определения причины проблемы - маловато данных.
Запускайте killall mysqld_safe ; mysqld_safe, может хоть так его ошибки увидим...
Если нужна проверка через переменную - тогда и её добавляйте в форму <input type="hidden" name="ed" value="edit">, а в условии не забудьте поменять $_GET на $_POST.
Хотя логичнее поменять условие на: if (!empty($_POST['id'])) {.
Ещё один момент, ваш код совершенно не защищён от вредоносных SQL-иньекций.
Открывайте вторую консоль в MySQL, и при повисании командой SHOW PROCESSLIST; смотрите, какие процессы чего делают. Может что-нибудь увидите...
Но скорее всего идет перестройка индекса. Можно перед всасыванием дампа сделать ALTER TABLE __tbl_name__ DISABLE KEYS;, конечно заменив __tbl_name__ на своё название заполняемой таблицы. Тогда индексы не будут перестраиваться, вплоть до выполнения команды ALTER TABLE __tbl_name__ ENABLE KEYS;. И вот после этого база задуууууумается...
Ещё вариант - в тексте дампа ищите последнюю попадающую в таблицу запись, а точнее какие запросы идут после этой записи. Может там какая-нибудь ошибка, глюк или некорректная комманда?
Эта ошибка сообщает вам, что систему inotify (слежение за изменениями файла) использовать не получается (упёрлись в лимит), будет использоваться периодическая проверка файла.
Самое простое решение - тупо игнорировать ошибку.
Ну так просто сотрите в строке extension=php_pdo_mysql.so это самое php_, и будет вам желанный результат. А PHP должен сам разобраться, какая именно версия из найденных 3-х ему доступна, и её загрузить. Если не загрузит - значит недоступна ни одна, и нужно этот модуль устанавливать.
Ну всё правильно, раз нет такого файла - то и не будет он подключаться как extension в PHP.
А вот прочитали-бы мой предыдуший ответ в этой ветке, осознали-бы его - глядишь и решилась-бы проблема.
ip route add xxx.xxx.xxx.63 dev ens23 table wan-63Но всё равно сомнительно, что broadcast-адрес куда-то удастся прислюнявить.