AUser0

Самый простой, элементарный, дуболомный вариант:
раз уж ваш скрипт запускается HTTP-запросом через HTTP-коннект - не давать этому HTTP-коннекту умирать по timeout-у. А значит надо каждые 25 секунд (а лучше каждые 20, да даже каждые 10 секунд) передавать в коннект любые валидные HTML-данные. Самое удобное - строку HTML комментария:
echo("<!-- empty line -->");flush();
Если поверх вывода накручены буфферы - проходить по всем буфферам и принудительно их ob_flush(), что бы строка улетела HTTP-клиенту.

Тогда и PHP, и Nginx, и браузер этот коннект по timeout-у - не закроют. Вуаля, профит!

А просто запустите программу Process Monitor от Sysinternals, и сами отследите, на какие диски какие программы свои файлы записывают.

P.S. А есть ещё гибридные диски, совмещающие возможности обоих типов - "винила" и "флэшек"...

70-C9-4E-54-03-2F, Загляните в Tools -> Packet Sniffer. Впишите туда "UDP" и 67-ой порт, и смотрите, какие пакеты откуда-куда приходят-уходят. Если правила работают - то будет логирован только приход пакетов на физический интерфейс, но не ответы на них... Поможет найти "мокрый пол".

P.S. Ну и логирование работы DHCP Server, тоже полезно видеть.

P.P.S. DHCP рассылаются броадкастом, может на них отвечает кто-то другой?

Вообще-то извещение о созданном посте нужно в случае, когда этот пост надо срочно прочитать или побыстрее промодерировать.

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

А что, этот код выполняется при каждом добавлении чего-то куда-то? Вот это вот обнуление arrCart, и потом добавление нового элемента в пустой массив, да?

pg_dump, если не возникает ни каких ошибок при его работе, собственно и НЕЧЕГО выводить в поток STDOUT и STDERR. Поэтому лог-файл и пустой. Смотрите содержимое файла из аргумента -f, там ваш SQL-дамп.

А вы что, не сообразили, что загрузка какой-то страницы - это и есть выполнение некоего скрипта?

У группы www-data нет прав на создание/удаление файлов в директории 9988e8e2-3414-4fa8-920d-268b80583022, в которой и лежит нужный .mp4. И не показали, какие права стоят на самом 9d6cc885-1c1d-4a33-a7f8-ac98ac18b7f7_1080.mp4, с которым пытается работать ffmpeg.

P.S. Самое простое - поставить на директорию с .mp4 права 0777, отработать ffmpeg-ом, и смотреть, какие пользователь:группа стоят на новых файлах... Ну и у .mp4 права такие-же, что бы точно читался.

А канонический telinit 1 в уже загруженной системе - не помогает?

Можно, но обычно так не делается.

Дайте команду ps axf - увидите в том числе процессы nginx, которые и обслуживают HTTP запросы. А происходит так скорее всего из-за режима GRACEFUL, когда каждый потомок продолжает обслуживать запросы пока они есть. Подождите минут 5-10, все потомки умрут - вот тогда трафик и остановится. Ну или можно сделать killall nginx

А нам теперь гадать на кофейной гуще, настроен ли у вас почтовый сервис, и какой, и запущен ли он, и нет ли ошибок, и прописан ли в нём ваш домен(ы), и открыты ли порты 25 и 110 и 465 и 587 и 993 и 995, да?
Как-то совсем неинтересненько получается...

P.S. И DNS нужно проверять у какого-нибудь Гуугла 8.8.8.8, да у CloudFlare 1.1.1.1.

Прописывайте все-все header-ы, которые в своём запросе отправляет настоящий браузер, в том числе cookie. Ну и раз уж смотрите его запросы - задно смотрите, документ скачивается сразу по запросу, или через какой-нибудь редирект?

Всё очень просто, пишите правила перенаправления для поддоменов на нужные TLD.

P.S. Каков вопроос - таков и ответ.

У вас в

в основном конфиге gitlab

и в /etc/nginx/conf.d/gitlab прописан один и тот же server_name gitlab.company.ltd;. Удалите один из server { ... } - конфликт пропадёт, очевидно же!

P.S. И уберите listen [::]:34080 default_server;, именно это не даёт стартовать nginx-у.

И опять, минимум подробностей. Компьютеры находятся в одной сети 192.168.1.X, так? VipNet стоит на каком именно компьютере? Только не надо отвечать "на левом" или "на втором", используйте слова "сервер" и "клиент". Проблема появляется после перезагрузки какого именно компьютера? И как удаётся восстановить доступ к сайту, или проблема возникла один раз и навсегда? IP-адреса компьютеров не поменялись, случаем? На сервере служба WEB-сервера запущена, активна? На клиенте команду telnet 192.168.1.40 6024 запускать пробовали, что команда выводит на экран? А на сервере? Службу VipNet отключать пробовали? Ах, да, и с какой именно ошибкой не получается доступ к сайту?

sudo chown -R apache /var/www/domain.local/