uWSGI: веб-сервер не может писать в сокет
Сокет создаёт uWSGI, и права на него задаются его настройками, а не unit-файлом. Если веб-сервер не входит в группу-владельца, обращения к приложению заканчиваются ошибкой шлюза.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Права на сокет не позволяют запись веб-серверу
По умолчанию сокет создаётся с правами владельца. Пользователь веб-сервера в них не попадает.
-
Каталог сокета не создаётся при запуске
Каталог в /run исчезает при перезагрузке. Без объявления через параметр systemd приложение не сможет создать сокет.
-
Путь в настройках веб-сервера не совпадает
Простая рассинхронизация: приложение создаёт сокет по одному пути, веб-сервер ищет по другому.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Права и владелец сокета.
sudo ls -l /run/myapp/Проверка доступа от пользователя веб-сервера.
sudo -u www-data test -w /run/myapp/uwsgi.sock && echo доступ есть || echo отказРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- По умолчанию сокет создаётся с правами владельца. Пользователь веб-сервера в них не попадает.
- Как проверить
-
Посмотрите права сокета и настройки.
sudo ls -l /run/myapp/uwsgi.sock grep -iE "chmod-socket|chown-socket|uid|gid" /etc/uwsgi/apps-enabled/myapp.ini 2>/dev/null
- Как исправить
- Задайте владельца и права сокета в настройках приложения: общая группа с веб-сервером и права 0660.
- Почему происходит
- Каталог в /run исчезает при перезагрузке. Без объявления через параметр systemd приложение не сможет создать сокет.
- Как проверить
-
Посмотрите каталог и параметр unit.
ls -ld /run/myapp 2>/dev/null systemctl show myapp.service -p RuntimeDirectory
- Как исправить
-
Объявите каталог через
RuntimeDirectory=: systemd создаст его с нужным владельцем при каждом запуске.
- Почему происходит
- Простая рассинхронизация: приложение создаёт сокет по одному пути, веб-сервер ищет по другому.
- Как проверить
-
Сравните пути.
sudo nginx -T 2>/dev/null | grep uwsgi_pass sudo ss -xln | grep uwsgi
- Как исправить
- Приведите пути к одному значению и перезагрузите настройки веб-сервера.
Пример вывода
Веб-сервер не может писать в сокет приложения. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
nginx[1121]: [crit] *12 connect() to unix:/run/myapp/uwsgi.sock failed (13: Permission denied) while connecting to upstream
$ sudo ls -l /run/myapp/uwsgi.sock
srw------- 1 app app 0 Sep 15 16:02 /run/myapp/uwsgi.sockСвязанные ошибки
- nginx 502 Bad Gateway: connect() failed к приложению nginx работает, а приложение недоступно: connect() failed, connection refused, no such file or directory для сокета. Разбор 502.
- Permission denied в журнале службы Отказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
- status=233/RUNTIME_DIRECTORY в systemd Код 233/RUNTIME_DIRECTORY: не удалось подготовить каталог службы в /run из RuntimeDirectory=. Права, режим, удаление при остановке.
- Puma слушает сокет, а веб-сервер получает отказ доступа Разъём между приложением и веб-сервером: сокет создаётся с правами приложения, читает его другой пользователь.
- status=235/CHOWN в systemd Код 235/CHOWN: не удалось изменить владельца сокета. Код относится только к unit-файлам сокетов.
- Служба не видит, кто обратился по сокету Сведения о вызывающем не приходят: передача учётных данных через сокет включается отдельно.
- Сокет с каналом: права не позволяют писать Служба принимает данные через канал, но клиенты не могут в него писать: владелец и права задаются в сокете.
- Фильтр почты недоступен почтовой службе: сокет и группы Почтовая служба не может обратиться к фильтру: сокет создан с правами, недоступными её пользователю.
Где встречается чаще всего
Источники
- Документация uWSGI: параметры сокета
-
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено сокетом с правами 0600 при обращении от веб-сервера.