Мда, из подробностей только 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.
А вот прочитали-бы мой предыдуший ответ в этой ветке, осознали-бы его - глядишь и решилась-бы проблема.
Тогда копайте, что именно передаётся на сайт при curl-запросе (доступно через curl_getinfo($ch, CURLINFO_HEADER_OUT) после выставления curl_setopt($ch, CURLINFO_HEADER_OUT, true);). И сравнивайте с правильным запросом.
Для проверки - обратитесь к какой-нибудь ещё странице сайта (GET /index.php например), и если запрос не приведёт к ошибке "устаревшая сессия" - значит не работает именно этот POST-запрос за AJAX-данными...
Ищите не файл php_pdo_mysql.so, а pdo_mysql.so.
Можно искать командой find /usr/lib/php/ -name pdo_mysql.so.
И в /etc/php.ini он уже должен быть вписан.
Подключите провод в сетевую карту enp5s0 (которая для Internet), сделайте ifup enp5s0 (если он сам атоматически не поднялся, проверять через ifconfig enp5s0, искать "state UP"), и потом пробуйте ping 8.8.8.8.
iptables никто и никогда и не адаптировал под fail2ban, он появился гораздо раньше.
Это скорее fail2ban заточен на использование iptables, потому что его возможности как раз подходят для задач fail2ban, вот тютелька-в-тютельку...
Значит не отрабатывает сама команда блокировки. Как правило используется iptables, ну или firewall типа ufw в случае Ubuntu. Копайте в эту сторону, в логах должны быть сообщения, в том числе и об ошибках...
Мда, всё выглядит очень чудесато.
Вот как так, прямой коннект - есть, а в браузерах - нет?
А может блокировка происходит при обращении к новому https-ному адресу, который в telnet уже не откроешь.
Можно попытаться процедить весь браузер-трафик через Wireshark или MITMProxy, может они что-то вскроют.
А может это срабатывает защита CloudFlare, блокирует вашу подсеть, потому что с неё был какой-нибудь вредный трафик? Но тогда бы и физического коннекта не было бы, я так думаю...
Для определения причины проблемы - маловато данных.
Запускайте
killall mysqld_safe ; mysqld_safe
, может хоть так его ошибки увидим...