SystemdDoctor
служба не работает ruby сокеты права

Puma слушает сокет, а веб-сервер получает отказ доступа

Приложение и веб-сервер работают от разных пользователей. Сокет создаётся с правами приложения, и веб-серверу в него не пробиться. Каталог сокета при этом должен пережить перезапуск и не оказаться во временной файловой системе, очищаемой при загрузке.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Права на файл сокета не дают доступа веб-серверу

    Сокет наследует права от создателя. Веб-сервер работает от своего пользователя и получает отказ.

  2. Каталог сокета исчезает после перезагрузки

    Каталог во временной файловой системе очищается при загрузке. Приложение не может создать в нём сокет.

  3. Веб-сервер обращается по устаревшему пути

    После правки пути сокета в приложении настройки веб-сервера остаются прежними. Он стучится туда, где ничего нет.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Существует ли сокет и с какими правами.

sudo ls -l /run/myapp/

Пользователь приложения и каталог сокета.

systemctl show myapp -p User -p Group -p RuntimeDirectory

Что именно получает веб-сервер при обращении.

sudo journalctl -u nginx -n 20 --no-pager | grep -i "connect() to unix"

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Права на файл сокета не дают доступа веб-серверу
Почему происходит
Сокет наследует права от создателя. Веб-сервер работает от своего пользователя и получает отказ.
Как проверить
Посмотрите права на сокет и пользователей обеих служб. 
sudo ls -l /run/myapp/puma.sock 2>/dev/null
systemctl show myapp -p User -p Group; systemctl show nginx -p User 2>/dev/null
Как исправить
Сделайте общую группу для приложения и веб-сервера и задайте права сокета так, чтобы группа могла писать. Права шире этого не нужны.
2. Каталог сокета исчезает после перезагрузки
Почему происходит
Каталог во временной файловой системе очищается при загрузке. Приложение не может создать в нём сокет.
Как проверить
Посмотрите каталог и параметры службы. 
systemctl show myapp -p RuntimeDirectory -p RuntimeDirectoryMode
sudo ls -ld /run/myapp 2>/dev/null
Как исправить
Объявите каталог через RuntimeDirectory= и задайте режим доступа: systemd создаст его при каждом запуске с нужными правами. 
[Service]
RuntimeDirectory=myapp
RuntimeDirectoryMode=0750
Group=www-data
3. Веб-сервер обращается по устаревшему пути
Почему происходит
После правки пути сокета в приложении настройки веб-сервера остаются прежними. Он стучится туда, где ничего нет.
Как проверить
Сравните путь в обеих настройках. 
grep -rhoE "unix:[^ ;]+" /etc/nginx/ 2>/dev/null | head
sudo ls -l /run/myapp/ 2>/dev/null
Как исправить
Приведите пути в соответствие и перезагрузите настройки веб-сервера. Ошибка доступа и ошибка отсутствия файла выглядят похоже, различает их точный текст в журнале.

Пример вывода

Веб-сервер не может писать в сокет приложения. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

nginx[1200]: 2026/09/15 17:20:41 [crit] 1200#0: *1 connect() to unix:/run/myapp/puma.sock failed (13: Permission denied) while connecting to upstream

$ sudo ls -l /run/myapp/puma.sock
srwxr-xr-x 1 deploy deploy 0 Sep 15 17:20 /run/myapp/puma.sock

Связанные ошибки

Где встречается чаще всего

Источники

  • systemd.exec(5)
    RuntimeDirectory= и режим доступа к каталогу.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено сокетом с правами только для владельца.     собственная проверка, systemd 255
    сверено 15 сентября 2026