Помилка сокета nginx unix домену

18

Я використовую fedora 17, і коли я встановлюю nginx за допомогою uwsgi за допомогою socket домену unix, коли я розміщую сокет у каталозі з належним дозволом, це нормально, але коли я розміщую сокет у /tmpньому, це призведе до помилки nginx:

connect() to unix:/tmp/MySite.sock failed (2: No such file or directory) while connecting to upstream

Цей файл існує та має дозвіл на читання / запис для користувача nginx. Але що викликає цю помилку, її насправді зводить мене з розуму, може хтось це зрозуміти.

nginx

— джефгоку
джерело

33

Ви не можете розміщувати розетки, призначені для міжпроцесорного зв'язку /tmp.

З міркувань безпеки останні версії Fedora використовують тимчасові каталоги в просторі імен , тобто кожна служба бачить зовсім інше /tmpі може бачити лише свої власні файли в цьому каталозі.

Щоб вирішити проблему, помістіть сокет в інший каталог, наприклад /run(раніше відомий як /var/run).

— Майкл Хемптон
джерело

1

/ run, але не є доступним для запису для звичайного користувача

— hostmaster

1

/runне підлягає запису безпосередньо, але ви можете доручити systemd створити під ним каталог, який можна записувати обома процесами.

— Майкл Хемптон

Щоб допомогти тим, хто шукає, це також стосується centos 7, і переміщення папки-сокетів у / запускається працювало. Знайти цю проблему непросто, оскільки кожен обліковий запис може бачити папку та файл у форматі tmp (встановити 777 на тестування), тому ви ніколи не здогадуєтесь, що процеси не зможуть.

— ДжозефК

0

ТАК! ЦЕ ДОПОМОГА!

Переглядав повідомлення uwsgi-log-startup-журналів, але не мав даних у журналах запуску, не зміг з’ясувати, що відбувається. Виявилося, мені потрібно було змінити файл шкарпетки на не-/ tmp місце та додати:

вилов-винятки = вірно

до ini-файлу wsgi. Виявилося, я вказав місце реєстрації файлообробника у неіснуючій каталозі, тому він не міг зафіксувати помилки в першу чергу.

— Кевін Дж. Райс
джерело