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

Для справки, мы также были бы признательны за эту функцию. Мы храним наши файлы журнала в пути, который периодически очищается от файлов и каталогов, которые не были затронуты в течение некоторого времени (и я ничего не могу с этим поделать). Это означает, что если мы остановим процесс на месяц, его каталог журналов исчезнет, ​​когда мы попытаемся перезапустить его, поэтому было бы неплохо, чтобы этот каталог автоматически воссоздавался.

+1 за этот вариант

+1

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

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

Я был бы рад внести свой вклад с запросом на вытягивание, мне просто нужны некоторые указатели относительно того, с чего я должен начать в коде.

Кроме того, я не знаю, должен ли я создать еще одну проблему для этого...

+1 ... очень разумная просьба, почему бы не выполнить ее?

Этого тоже не хватает....

Есть ли обходной путь, который хотя бы позволит нам создать каталог из файла конфигурации? Может, запустить внутрь mkdir ?

+1

Мы, пользователи докеров, должны сделать это

1. ENTRYPOINT["sh", "/entrypoint.sh"] в Dockerfile
2. В /entrypoint.sh создайте каталог журналов и файлы журналов перед вызовом supervisord

Это сценарий оболочки для /entrypoint.sh для автоматического создания их из supervisord.conf .

# Create log dirs and files
mkdir -p $( dirname $(cat /etc/supervisord.conf  | grep logfile= | grep "\.log" | sed s/.*logfile=// ) )
touch $( cat /etc/supervisord.conf  | grep logfile= | grep "\.log" | sed s/.*logfile=// )

# Then run supervisord
/usr/bin/supervisord

Есть ли хорошая идея?

+1

supervisord не запускается при загрузке Arch Linux, поскольку при загрузке /var/log/supervisord.log не существует.

Вот более подробная информация о том, почему это было бы полезно в моем случае.
Я использую супервизор в докере для запуска некоторого программного обеспечения, для которого я хочу сохранить журналы, поэтому люди монтируют том. Но поскольку supervisord не создает необходимые подкаталоги, пользователям требуется создавать каталоги на хосте и самостоятельно устанавливать владельца и разрешения. И это невозможно поместить в директиву command , так как supervisord жалуется и останавливается еще до просмотра command .

@mnaberez почему придерживаешься своего отказа? Я видел более веские аргументы в пользу этого, чем в вашем отказе .... (но я могу что-то упустить, поэтому приветствуются дополнительные объяснения ;-)

Это продолжает оставаться проблемой, особенно для пользователей, развертывающих супервизор в Docker в среде ElasticBeanstalk. Если вы укажете ведение журнала в Dockerrun, служба стирает указанные каталоги во время развертывания, удаляя все, что было создано во время раскрутки Docker. Это, в свою очередь, нарушает работу супервизора, поскольку он ожидает файлы там, где их нет. Если бы супервизор просто создавал каталоги и журналы, когда их не существовало, это полностью решило бы проблему. В нынешнем виде мне пришлось отключить дискретные файлы журналов (и вместо этого использовать системный журнал), чтобы развернуть мое приложение.

то же самое здесь, я использовал следующий обходной путь:
docker run -v /mnt/my_logs/celery:/var/log/celery -v /mnt/my_logs/supervisor:/var/log/supervisor -v /mnt/my_logs/supervisor:/var/log/supervisor -v / mnt/my_logs/nginx:/var/log/nginx -v /mnt/my_media:/home/project/media -p 80:80 -p 5555:5555 -d my_project

Я тоже сталкиваюсь с этим сейчас. У меня есть Raspberry Pi, на котором /var/log смонтирован на tmpfs для предотвращения записи на SD-карту. После перезагрузки устройства папка /var/log/supervisor исчезла и супервизор не запускается. Автоматическое создание этого каталога было бы очень кстати.

@mnaberez не могли бы вы передумать? Были также предложения PR для этой функции.

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

:+1: Я тоже только что столкнулся с этим.

+1 👍 Мне тоже было бы очень полезно.

Пожалуйста, напомните здесь.
Если супервизор был установлен по умолчанию и не меняйте путь к журналу из /tmp/supervisord.log, в некоторых системах, таких как CentOS 7.3 или выше, systemd-tmpfiles-clean.timer каждый день будет выполнять cron для удаления всего в /tmp .
Мы очень страдаем от этого...

Я только что отредактировал файл /etc/supervisor/supervisord.conf и изменил эти строки;

logfile=/var/log/supervisor/supervisord.log до logfile=/var/log/supervisord.log
childlogdir=/var/log/supervisor до childlogdir=/var/log/

и исправлено для меня. И у меня была точно такая же ситуация с @adamreisnz :)

докера не было рядом, когда возникла эта проблема. Итак, в настоящее время мы используем супервизор в докере. спасибо хороший инструмент.

однако, если мы хотим перенаправить выходные данные, нам нужно добавить новую строку (и она создает новый слой) в файл докеров, например mkdir /var/log/supervisord/"

если супервизор создаст каталог, то это будет хорошо. Спасибо, в любом случае.

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

Удар

+1

@mnaberez Во-первых, супервайзер — отличный инструмент. Из-за того, что супервизор запускается первым (до того, как каталог журнала может быть создан запускаемой программой), интуитивно понятно, что он может создать каталог журнала сам, если он еще не существует. Есть ли какое-либо другое логическое объяснение, чтобы не добавлять эту опцию, кроме комментария «... файл конфигурации уже довольно многословен ...»?

Из-за того, что супервизор запускается первым (до того, как каталог журнала может быть создан запускаемой программой)

Если вы начинаете myprogram напрямую:

command = myprogram

Вместо этого вы можете начать его с чего-то вроде:

command = bash -c 'mkdir /foo && exec myprogram'

:+1: +1 к этому запросу

1063

+1 хотел бы использовать имя программы в пути журнала. не совсем очевидно, почему супервизор не запускается, когда это происходит

Также недавно возникла такая же проблема. Был очень удивлен, что он не справился с этим внутри.

@mnaberez Вы предлагаете указать его в команде, но это не работает для журналов супервизора, как я написал в комментарии в этой теме:

And it is not possible to put it in the command directive, as supervisord complains and 
stops even before looking at the command

Можете ли вы создать каталоги перед запуском супервизора, например, в сценарии инициализации или его эквиваленте, который запускает супервизор? Почему бы нет?

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

Также совершенно очевидно, что большинство программного обеспечения на самом деле делает это, поэтому справедливо, что люди ожидают этого.

Более того, из отзывов в этой ветке видно, что способ обработки этой ошибки неясен и сбивает людей с толку, и что многие из них не понимают, почему супервизор не работает.

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

Только в этой ветке 26 участников, а это значит, что по крайней мере в 10 раз больше людей, которые не удосуживаются комментировать здесь, но думают так же по этому вопросу. Если есть такое сильное желание запросить то, что на первый взгляд является довольно тривиальной функцией, то почему бы просто не реализовать ее или не отправить кому-нибудь PR?

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

http://supervisord.org/logging.html
http://supervisord.org/faq.html
http://supervisord.org/installing.html

Ни на одной из этих страниц ничего не говорится о необходимости создавать каталоги журналов вручную.

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

Также совершенно очевидно, что большинство программного обеспечения на самом деле делает это, поэтому справедливо, что люди ожидают этого.

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

Более того, из отзывов в этой ветке видно, что способ обработки этой ошибки неясен и сбивает людей с толку, и что многие из них не понимают, почему супервизор не работает.

Это фактическое сообщение об ошибке:

Error: The directory named as part of the path /nonexistant/cat/stdout.log does not exist in section 'program:cat' (file: 'supervisord.conf')
For help, use /usr/local/bin/supervisord -h

Если это непонятно, как это можно переформулировать?

Если есть такое сильное желание запросить то, что на первый взгляд является довольно тривиальной функцией, то почему бы просто не реализовать ее или не отправить кому-нибудь PR?

• Текущее поведение предотвращает ошибки конфигурации. В настоящее время, если в системе есть каталог /var/log/ , но вы случайно ввели /var/logs/foo.txt в файл конфигурации, supervisord остановится с ошибкой, указанной выше. Я думаю, что это лучше, чем закончить с /var/log/ и /var/logs/ и, возможно, не замечать этого долгое время.

• Что именно означает автоматическое создание каталога? Означает ли это mkdir или mkdir -p ? Какими должны быть chown и chmod автоматически созданных каталогов? В настоящее время пользователь настраивает все эти вещи за пределами supervisord с помощью оболочки. Нужно ли в конфигурационном файле иметь кучу опций, чтобы указать их все сейчас? Если другие программы имеют такое поведение, может ли кто-нибудь привести конкретные примеры?

• Это просто журналы или это должно относиться и к другим путям, например, pidfiles? Почему или почему нет? Если нет, то не лучше ли быть последовательным и не создавать никаких каталогов, чем создавать одни, а не другие?

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

Быстрый отказ — распространенный подход, когда демоны и другое серверное программное обеспечение запускаются с плохой конфигурацией. Нет документации, указывающей, какие параметры конфигурации могут быть недействительными, а какие нет, потому что ни один из них не является таковым.

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

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

@mnaberez Моя основная причина, по которой я попросил эту функцию, заключалась в том, что я использовал супервизор в докере. Контейнеры Docker не имеют системы инициализации и предназначены для запуска только одной команды. Когда людям нужно запустить несколько процессов в одном контейнере, suprevisord отлично подходит, за исключением этой проблемы.
Когда пользователи хотят сохранить журналы команд, запускаемых супервизором, они монтируют том, на котором супервизор сохраняет журналы приложения. Из-за этой проблемы им необходимо знать иерархию каталогов для создания.

Конечно, всегда есть оправдание, чтобы отказаться от его реализации («если докер для одной команды, вы не используете его по назначению, если вам нужен супервизор», или «люди должны знать, что происходит в образе»), но почему бы и нет просто облегчить жизнь своим пользователям, интегрировав его?

Я пытался найти разумное решение для создания каталогов, в которые supervisord отправляет журналы, но ни одно из них не работало (добавьте создание файла журнала в command="mkdir blah && command" ), а также простое и удобное в обслуживании (проанализируйте файл журнала для создания каталогов перед запуском надзиратель).

Конечно, всегда есть оправдание, чтобы отказаться от его реализации («если докер для одной команды, вы не используете его по назначению, если вам нужен супервизор», или «люди должны знать, что происходит в образе»), но почему бы и нет просто облегчить жизнь своим пользователям, интегрировав его?

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

Подробные ответы я писал выше ( здесь и здесь ). На них необходимо ответить, чтобы добиться прогресса в этом вопросе. Эти вопросы открыты для всех, кто просит об этом изменении.

Что касается «почему бы не облегчить жизнь своим пользователям?» и подобные комментарии, я, очевидно, потратил много времени, отвечая на комментарии здесь и пытаясь лучше понять этот вопрос. Я действительно забочусь о пользователях, поэтому я провел почти десять лет, поддерживая это программное обеспечение, исправляя проблемы и отвечая на список рассылки. Когда вы отправляете подобные комментарии мейнтейнерам с открытым исходным кодом, это делает и без того неблагодарную задачу невыносимой и приводит к выгоранию.

Изменить: изменена формулировка;

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

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

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

Так кто несет ответственность в этом случае? Вы говорите, что supervisord не ведет журнал по умолчанию, поэтому Dataplicity использует supervisord и (предположительно) настраивает его на использование файла журнала. Но тогда Dataplicity ничего не знает о состоянии машины, на которой он работает, поэтому они также не могут знать, какие папки журналов создавать. Пользователь застревает посередине, потому что он не знает, что ему нужно создать папку журнала, пока не столкнется с ошибкой после перезагрузки. Так что это немного похоже на ситуацию с курицей и яйцом.

Для всех других демонов, которые я запускаю, я создаю необходимые каталоги перед их запуском. В любом случае, перед запуском демона вам нужно выполнить некоторые действия, например, вы должны создать файл конфигурации. Почему тогда каталог не может быть создан?

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

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

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

@mnaberez Большое спасибо за повторное рассмотрение этого вопроса и за все ответы. Я просматривал свои первоначальные комментарии (столько лет назад), чтобы лучше понять, почему я вообще создал эту проблему.

Я полагаю, что моим первоначальным желанием было, чтобы супервизор мог создавать каталог файлов журналов программ, которыми он управляет, а не каталог своих собственных журналов. И это все еще то, что я должен сделать некоторые обходные пути в настоящее время. Возможно, потому, что мое использование супервизора несколько отличается от ожидаемого: я постоянно его обновляю, добавляя и удаляя программы несколько раз в минуту.

Я разделяю многие из ваших опасений по поводу создания собственных каталогов журналов супервизора. И если подумать, я решил обе проблемы одинаково: для супервизора я создаю каталоги журналов в файле инициализации (в настоящее время systemd), а для программ я использую своего рода «скрипт инициализации» (bash) для затем, и этот сценарий отвечает за создание каталогов журналов, если они не существуют (и «выполняет» программу после этого).

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

В ответ на все комментарии здесь. Я бы сказал дополнительно, что абсолютно, если это трудно сделать, простое улучшение сообщений об ошибках и фактическое документирование этого в различных местах и ​​в процессе установки упростит процесс для пользователей.

Основная причина, по которой я пришел сюда, заключалась в том, что я провел хороший час, переустанавливая, изменяя настройки, перечитывая документацию, чтобы попытаться понять, в чем проблема и почему она «просто не работает» после следования инструкциям по установке. Если бы в этих инструкциях было сказано: «Если вы хотите настроить путь к журналам, вам нужно сначала убедиться, что каталог существует и имеет соответствующие разрешения», то я бы вообще не запутался.

Разрешения на доступ к папкам — распространенная проблема, поэтому я не думаю, что наличие небольшой документации по этому вопросу как части установки негативно повлияет на этот процесс.

Что касается «почему бы не облегчить жизнь своим пользователям?» и подобные комментарии, я, очевидно, потратил много времени, отвечая на комментарии здесь и пытаясь лучше понять этот вопрос. Я действительно забочусь о пользователях, поэтому я провел почти десять лет, поддерживая это программное обеспечение, исправляя проблемы и отвечая на список рассылки. Когда вы отправляете подобные комментарии мейнтейнерам с открытым исходным кодом, это делает и без того неблагодарную задачу невыносимой и приводит к выгоранию.

@mnaberez Я рад, что вы пересмотрели эту просьбу, и я ценю вашу преданность своему проекту. Мои комментарии всегда были уважительными, и я чувствую, что мой вопрос оправдан для запроса с постоянным интересом пользователей с 2012 года.

Что касается самого запроса, проблема, с которой я столкнулся, заключается в том, что supervisord жалуется на несуществующий каталог журнала перед запуском команды. Проще всего было бы позволить пользователю создавать каталоги либо комбинируя их в команде (например, mkdir /var/log/supervisord && mycommand ), но это может иметь некоторое влияние на внутренности, либо используя директиву PreCommand для для которых наличие лог-каталога не требуется.

Мои комментарии всегда были уважительными, и я чувствую, что мой вопрос оправдан для запроса с постоянным интересом пользователей с 2012 года.

Негативные комментарии вроде вашего «почему бы просто не облегчить жизнь своим пользователям?» никогда не являются уважительными или оправданными.

Никто из сопровождающих этого проекта намеренно не пытается усложнить жизнь пользователям. Мы сами являемся пользователями программного обеспечения. Нет никакого стимула усложнять жизнь пользователям. Это только создает больше запросов в службу поддержки, с которыми нам приходится иметь дело. Почти всегда есть другая причина, по которой конкретная вещь не выполняется определенным образом, кроме того, что сопровождающие не заботятся о пользователях. Для существующего поведения были веские причины, которые уже объяснялись в ветке.

Я не уверен, что следует делать по этому вопросу, но я согласен с @adamreisnz и @Dayjo в том, что обновление документации для уточнения текущего поведения является хорошим первым шагом.

Негативные комментарии вроде вашего «почему бы просто не облегчить жизнь своим пользователям?» никогда не являются уважительными или оправданными.

В качестве моего последнего комментария по этому вопросу я рекомендую вам прочитать http://www.dealingwithdisrespect.com . Я чувствую, что мой комментарий приемлем и далеко не противен .

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

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

Так кто несет ответственность в этом случае?

Я не знаком с Dataplicity, но вы также можете сообщить об этой проблеме в Dataplicity.

Сам Supervisor не занимается установкой. Это просто пакет Python. Он не предоставляет официальных сценариев инициализации или даже файла конфигурации, он предоставляет только команду echo_supervisord_conf , которая выводит пример файла конфигурации на стандартный вывод. Лицо, переупаковывающее или устанавливающее Supervisor, несет ответственность за создание конфигурации, совместимой с целевой системой.

Если я правильно понимаю, Dataplicity установила Supervisor для вас, но то, как он был установлен, не выдержит перезагрузки вашей системы. Каталоги журналов изначально создавались Dataplicity, но не сохранялись после перезагрузки, поскольку находились в tmpfs. Если Dataplicity создает сценарий инициализации, который запускает Supervisor, они могут изменить сценарий инициализации, чтобы он сначала проверял каталоги и при необходимости создавал их (то же решение, что и вы). Они также, вероятно, захотят отслеживать этот тикет, потому что даже если в Supervisor будут внесены изменения или добавлена ​​новая функция, Dataplicity может не выбрать новый выпуск автоматически, если они привязаны к определенной версии.

@adamreisnz @mnaberez

Наш агент установки Dataplicity загружает и устанавливает супервизор. Когда он загружается, он имеет все настройки, настроенные выше по течению, мы ничего не меняем. Каталог по умолчанию, который супервизор использует для ведения журнала, можно увидеть в файле ниже. Это то, что вы, вероятно, захотите настроить, если хотите, чтобы ваши журналы хранились в другом месте.

cat /etc/supervisor/supervisord.conf

; supervisor config file

[unix_http_server]
file=/var/run/supervisor.sock   ; (the path to the socket file)
chmod=0700                       ; sockef file mode (default 0700)

[supervisord]
logfile=/var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log)

--- ... shortened output ... ---

Что касается журналов, специфичных для Dataplicity, ниже приведен наш модульный файл для супервизора, в котором указано, где мы их храним.

cat /etc/supervisor/conf.d/tuxtunnel.conf

--- ... shortened output ... ---

stdout_logfile=/var/log/dataplicity.log
stderr_logfile=/var/log/dataplicity.log

В качестве альтернативы, если вы хотите сохранить файлы журнала там, где они есть, и просто убедиться, что супервизор работает с tmpfs, вот что вы можете добавить в свой файл /etc/rc.local :

if [ ! -d /var/log/supervisor ]; then
        mkdir /var/log/supervisor;
        touch /var/log/supervisor/supervisord.log
        chown -R dataplicity:dataplicity /var/log/supervisor;
        service supervisor restart
fi

Надеюсь это поможет,
Радослав из Dataplicity

@mnaberez @Radoslaw-K

Наш агент установки Dataplicity загружает и устанавливает супервизор. Когда он загружается, он имеет все настройки, настроенные выше по течению, мы ничего не меняем. Каталог по умолчанию, который супервизор использует для ведения журнала, можно увидеть в файле ниже.

Так это настройки супервизора по умолчанию? Насколько я понял из того, что написал @mnaberez ;

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

Я думал, что Supervisor не создает никаких журналов и не указывает какие-либо каталоги журналов по умолчанию.

Таким образом, либо Dataplicity должен указывать эти каталоги, либо супервизор должен иметь их по умолчанию. Если первое, то, вероятно, этого делать не следует. Если это последнее, то я думаю, что может потребоваться изменить значения по умолчанию, чтобы вообще не вести журнал или автоматически создавать каталог по умолчанию.

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

@adamreisnz

Это настройки супервизора по умолчанию, правильно.

Вы правы в том, что:

_ "Не имеет особого смысла иметь каталог по умолчанию, но не иметь возможности запустить приложение, потому что каталог не существует."_

Ребята из emonpi, которые в прошлом устанавливали dataplicity в своей системе, столкнулись с той же проблемой, и я думаю, что об этом сообщили разработчикам Supervisor, но их ответ заключался в том, что пользователь несет ответственность за создание этого каталога, если он не существует.

Лучший,
Радослав из Dataplicity

Это настройки супервизора по умолчанию, правильно.

Это неправильно, потому что этот проект (Supervisor) вообще не предоставляет сценарии инициализации или файлы конфигурации ( подробнее см. выше ). Мы предоставляем только команду echo_supervisord_conf , которая записывает образец конфигурации в стандартный вывод. Я посмотрел на вашу конфигурацию выше , и она не соответствует тому, что выводит echo_supervisord_conf (например, каталоги /var/run и /var/log нигде не появляются в этом образце вывода). Вы используете конфигурацию, созданную и записанную на диск кем-то другим.

Наш агент установки Dataplicity загружает и устанавливает супервизор. Когда он загружается, он имеет все настройки, настроенные выше по течению, мы ничего не меняем.

Проект Supervisor предоставляет только те пакеты Python, которые опубликованы в PyPI . Наши пакеты обычно устанавливаются с pip . Наши пакеты не содержат сценариев инициализации или файлов конфигурации. Похоже, вы устанавливаете пакет из другого источника, например, вы установили его с помощью команды вида apt или rpm . Это сторонние пакеты, созданные другими лицами, не участвующими в основном проекте Supervisor. Мы мало что знаем об этих пакетах и ​​не можем вносить в них изменения. Любые сценарии инициализации или файлы конфигурации исходят от них. Я предлагаю связаться с сопровождающими стороннего пакета, который вы устанавливаете. Только они могут изменить свой сценарий инициализации по умолчанию для создания каталогов.

Всем привет,
Я просто пишу здесь, чтобы немного дополнить и прояснить одну или две вещи, поскольку Dataplicity упоминался здесь более одного раза :-)

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

Точная проблема для нас уже довольно хорошо описана выше. Поведение в отношении создания каталога журнала, если он не существует, не является беспрецедентным. В частности, nginx ведет себя аналогично (не создает каталог), как и ряд других основных сервисов. Так случилось, что @adamreisnz создал довольно хороший список в репозиториях emonpi, где каждый сервис, у которого есть эта проблема, должен был быть обманут точно таким же образом.

Если бы я сделал довольно широкое наблюдение, то сейчас новым, по сравнению с тем, что было пять лет назад, является то, что запись в энергозависимое хранилище становится все более распространенным явлением. Точнее, с массовым появлением устройств IoT (таких как Raspberry Pi) и таких систем, как Docker и Amazon EBS, люди все больше полагаются на tmpfs как на быструю систему ведения журналов, которая не изнашивает флэш-память. Это не проблема уровня дистрибутива — Ubuntu, Arch и Slackware одинаково затронуты.

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

В случае Dataplicity это влияет на нас, потому что SBC, включая Raspberry Pi, обычно используют tmpfs для хранения журналов, чтобы предотвратить износ флэш-памяти. И в большинстве этих систем это означает, что /var/log — это новая файловая система без каталогов в момент загрузки. Это означает, что супервизор прерывается при запуске, потому что он не может получить доступ к ожидаемому каталогу.

Для ясности:
1) агент dataplicity — это демон на стороне устройства, который работает на пользовательских устройствах, обычно Raspberry Pi, для подключения устройства к службе dataplicity.
2) Агент использует супервизор, чтобы гарантировать, что мы работаем в качестве непривилегированного пользователя в системе, а также для обработки таких вещей, как автоматический перезапуск агентов и т. д.
3) Установщик Dataplicity использует apt-get в системах, где он доступен, что означает, что да, процесс установки супервизора основан на сочетании источника программного обеспечения (здесь) и точных инструкций по установке, встроенных в пакет apt людьми, занимающимися распространением. в Debian/Ubuntu и т. д.

Есть три места, где мы (Dataplicity) могли бы что-то добавить для создания этого каталога при загрузке, но единственное (для нас) без существенных недостатков — это если супервизор должен был сам создать ожидаемый каталог при запуске.

Уровень 3 (на уровне установщика/агента dataplicity)

• Мы можем добавить выдумку в установщик dataplicity, чтобы создать каталог. Это не сработает, потому что каталог tmpfs и не выдержит перезагрузки.
• Мы можем поместить другую выдумку в установщик dataplicity, чтобы изменить rc.local, или в сценарий запуска супервизора, чтобы каждый раз создавать этот каталог при загрузке. В нашем тестировании платформы используют rc.local непоследовательно, а это означает, что мы не можем полагаться на это для каждого дистрибутива, включая те, в которых люди создают свои собственные сборки (довольно часто для наших пользователей). Последнее правдоподобно, но также в конечном итоге зависит от платформы и конфликтует со стандартными пакетами дистрибутива, поэтому обновления дистрибутива и т. д. будут постоянно бороться с нашей маленькой выдумкой. Помимо Dataplicity, вряд ли можно было ожидать такого поведения для _каждой_ установки в одной и той же ситуации.
• Мы можем изменить конфигурацию супервизора по умолчанию. Однако, учитывая, что супервизор может использоваться многими вещами в одной и той же системе, допущение о том, что множественность данных — это единственное, что «управляет» супервизором на машине, является довольно убедительным предположением: люди могут быть недовольны нами, если мы непреднамеренно уничтожим другие службы, работающие на их машине.

Суть в том, что это немного похоже на выдумку, что после того, как мы выполним «apt-get install supervisor», мы должны сделать «mkdir /var/log/supervisor/», просто чтобы это заработало.

Уровень 2 — Распространение

• Мы можем попросить каждого дистрибьютора изменить процесс установки, чтобы определенные каталоги создавались каждый раз при загрузке системы. Как оказалось, пакет apt-get уже создает начальный каталог, потому что он соответствует файлам конфигурации шаблонов, которые они предоставляют. Но это не учитывает тот факт, что так много систем работают на tmpfs, а это означает, что он не переживет первую перезагрузку.

Уровень 1 - сам руководитель.

• Я понимаю, что это потенциально добавляет еще один слой. Но, кроме создания каталога, я не вижу никаких недостатков (конечно, я мог что-то упустить).
• Преимущество в том, что это поведение будет просачиваться вниз и означает, что каждый дистрибутив, поддерживающий временную файловую систему (или эквивалентную), в конечном итоге получит такое поведение, а это означает, что нам не нужно убеждать каждый дистрибутив использовать эту выдумку.

Надеюсь, это поможет.

Эллиот (Dataplicity)

Суть в том, что это немного похоже на выдумку, что после того, как мы выполним «apt-get install supervisor», мы должны сделать «mkdir /var/log/supervisor/», просто чтобы это заработало.

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

всем привет

У нас есть несколько вариантов, но этот конкретный, вероятно, приведет меня к отставке: внесение этого изменения для всех платформ, которые мы поддерживаем, равнозначно каждому дистрибутиву от Red Hat до Arch через Ubuntu и Debian между ними. И это также упускает из виду тот факт, что встроенный супервизор не работает в системах с изменчивым хранилищем журналов.

Есть ли что-то, что я упускаю здесь, что представляет собой особую проблему или аргумент против этого? Может ли это вызвать проблемы с обслуживанием или развертыванием, о которых я не знаю?

Лучший
Эллиот

Есть ли что-то, что мне здесь не хватает

Да. Устанавливаемые вами сторонние пакеты часто значительно отстают от основной версии Supervisor, часто на годы. Даже если в Supervisor будет внесено изменение (которое обсуждается здесь, этот вопрос все еще открыт), оно может не помочь вам в течение очень долгого времени, если вы будете ждать, пока эти третьи стороны упакуют новую версию. Если вы сообщите о проблеме сопровождающим пакета, который вы устанавливаете, они могут захотеть исправить сценарии инициализации своих текущих пакетов.

Теперь, когда я могу полностью понять.

Меня, однако, всегда заботит то, что является лучшим решением, а несколько позже следует то, что является самым быстрым.

Так что я действительно вижу здесь две проблемы. Один из них решает эту проблему наилучшим образом, и мое личное предложение состоит в том, чтобы добавить это во все исходные пакеты (я также открыт для лучших решений).

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

Один из них решает это наилучшим образом, для чего я лично предлагаю добавить это во все исходные пакеты.

Нам было бы интересно узнать ваше (или чье-либо) мнение по приведенным выше вопросам . Был запрос на вытягивание, который молча и автоматически создавал любой отсутствующий каталог. Я не думаю, что это правильно по причине, упомянутой выше, но я не уверен, как должна выглядеть новая опция.

@mnaberez Я вижу твой вопрос.

Инженерная сторона меня говорит, что все должно быть абсолютно согласовано. Но практическая сторона меня говорит, что это проблема, связанная в первую очередь с /var/log, существующим на tmpfs, и я не слышал жалоб в другом месте. В целом, я бы предложил, чтобы решение можно было сфокусировать на узком направлении до тех пор, пока не будет сочтено целесообразным расширить охват.

Самый узкий вариант, который я могу придумать, это действительно неявный mkdir. Я полагаю, что проблемы, которые мы наблюдаем, связаны с отсутствием /var/log/supervisor/ при загрузке, а не с отсутствием /var/log, и что на практике я довольно редко сталкивался с системой, в которой нет каталог регистрации верхнего уровня, указанный дистрибьютором.

Завтра дам более взвешенный ответ.

Вместо того, чтобы неявно создавать каталоги, может ли быть явный раздел в conf для обеспечения существования каталогов до разветвления процесса?

Что-то в этом роде:

[directory:log]
path=/foo/bar/baz
owner=www-data
create=true
recursive=true

Если вы просто укажете путь, произойдет сбой, если этот путь не существует (что само по себе может быть полезно). Но create=true объявляет, что вы хотите его создать (если он не существует), а recurse=true объявляет, что вы хотите создать любые родительские каталоги.

Я согласен с тем, что неявное создание каталогов, вероятно, вызывает ошибки, и изменение поведения сейчас, вероятно, будет раздражать столько людей, сколько заблагорассудится. Но приведенное выше не изменит текущее поведение, но по-прежнему даст разработчикам возможность автоматического создания каталогов журналов (например).

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

В моем случае я развертываю свое приложение в два этапа:

1. Bootstrap сервер с помощью шеф-повара (установите пакеты и создайте файлы конфигурации).
2. Разверните приложение с помощью capistrano (загружает приложение с github и перезапускает определенные службы с помощью supervisorctl restart my_group:*.

Я запускаю 1-й шаг в первый раз, когда загружаю новую машину или когда делаю какие-либо изменения в программном обеспечении или конфигурации системы. 2-й шаг выполняется для выпуска новой версии кода приложения.

Итак, после самого первого запуска шеф-повара я получаю сломанный супервизор (сервис мертв), потому что он не может найти каталог. Затем запустите capistrano, чтобы развернуть приложение в первый раз (он создаст все необходимые каталоги) и попытается перезапустить службы с помощью supervisorctl, но это не удается. Так что мне нужно запустить шеф-повара еще 1 раз, что доставляет неудобства.

Я считаю, что если что-то не так с конфигурацией одной программы, то сам демон супервизора должен запуститься, но программа должна быть в состоянии сбоя.

+1

Если мне нужны какие-то сценарии-оболочки для самого супервизора, это противоречит самой цели программы. Я думаю, что он должен автоматически создавать всю ветку каталога по умолчанию. Может быть возможность _отключить_ это поведение, а не наоборот.

На самом деле сейчас есть две основные проблемы с поведением супервайзера:

1. Не создавать ветку каталога автоматически.
2. Полное отключение только потому, что некоторые файлы журналов не могли быть созданы. Это еще хуже, чем первая проблема. (Это рассматривается в № 1143, который, я думаю, _не_ является дубликатом.)

@mnaberez написал:

Текущее поведение предотвращает ошибки конфигурации. В настоящее время, если в системе есть каталог /var/log/, но вы случайно ввели /var/logs/foo.txt в файле конфигурации, supervisord остановится с указанной выше ошибкой. Я думаю, что это лучше, чем закончить с /var/log/ и /var/logs/ и, возможно, не замечать этого долгое время.

_гипотетическая_ проблема случайного создания лог-файлов в немного неправильном месте кажется мне гораздо меньшей проблемой, чем очень реальная и частая (так и должно быть) проблема вывода из строя всего сервера только потому, что администратор забыл создать папку для журнальный файл.

А что если перепутать имя файла, а не папки? Что, если вы создадите журнал в неправильном месте, но тем не менее он существует? Что, если вы укажете совершенно бессмысленное имя в существующей папке? Ведь, знаете ли, мусор на входе, мусор на выходе.

Другой аспект этого вопроса заключается в том, что концептуально полные пути к файлам можно рассматривать как полные имена файлов. То есть файловую систему можно рассматривать как набор файлов с именами, в именах которых есть косая черта, а не как дерево папок. Однако эту коллекцию можно рассматривать и как дерево папок в другом представлении. Что приводит нас к:

Что именно означает автоматическое создание каталога? Означает ли это mkdir или mkdir -p?

mkdir -p, конечно. Чисто с практической точки зрения пользователю не приходится иметь дело с некоторыми скриптами-оболочками или зависимыми последовательностями команд.

Какими должны быть chown и chmod автоматически созданных каталогов?

Как насчет того, чтобы они соответствовали chown и chmod созданного файла журнала? Вы сами создаете файл журнала, не так ли? Почему бы также не создать каталог?

В настоящее время пользователь настраивает все эти вещи за пределами супервизора с оболочкой.

... чего они сначала не делают, но узнают об этой проблеме после того, как их сервер неожиданно выходит из строя.

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

Это просто журналы или это должно относиться и к другим путям, например, pidfiles? Почему или почему нет?

Ну, это звучит так, как будто это выходит за рамки текущего выпуска.

Если нет, то не лучше ли быть последовательным и не создавать никаких каталогов, чем создавать одни, а не другие?

Нет. Разные ситуации требуют разного подхода. Журналы отличаются, например, от критических файлов, целостность которых жизненно важна для системы. Журналы важны, но не являются критическими или жизненно важными. ~Если некоторые журналы не могут быть созданы, вы можете выдать предупреждение, и пользователь позже исправит их. Это намного лучше, чем выключать всю систему только потому, что один файл журнала не был создан. ~ Редактировать : здесь я потерял цепочку мыслей. Аргумент был об автоматическом создании структуры папок для лог-файлов, поэтому проблема, от которой мы здесь защищаемся, заключается в том, что имя папки для какого-то лог-файла может быть неправильным. Таким образом, учитывая, что лог-файлы и их расположение обычно не являются критическими или жизненно важными, я бы с удовольствием променял риск размещения лог-файла в неправильной папке на риск неожиданного отключения сервера. Для (предположительно редких) людей, для которых расположение файлов журнала имеет решающее значение, я бы предоставил возможность подписаться, чтобы убедиться, что папка для файла журнала существует.

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

Это мнение зависит от приложения. Мы не будем гадать о том, насколько важными могут быть лог-файлы для чужого приложения. Если пользователь предоставляет файл $#$ supervisord.conf supervisord не может выполнить, он быстро выйдет из строя, поэтому проблема будет исправлена ​​раньше, чем позже.

@мнаберез

Журналы отличаются, например, от критических файлов, целостность которых жизненно важна для системы. Журналы важны, но не являются критическими или жизненно важными. ...

Это мнение зависит от приложения.

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

Мы не будем гадать о том, насколько важными могут быть лог-файлы для чужого приложения.

Но вы догадались, что выход из строя всей системы менее критичен, чем вероятность того, что имя папки для одного файла журнала может быть неправильным. По сути, если нам приходится выбирать между этими двумя бедствиями (перебоем службы и, возможно, неправильным именем папки для файла журнала), некоторые догадки кажутся неизбежными.

Но вы догадались, что выход из строя всей системы менее критичен, чем вероятность того, что имя папки для одного файла журнала может быть неправильным. По сути, если нам приходится выбирать между этими двумя бедствиями (перебоем службы и, возможно, неправильным именем папки для файла журнала), некоторые догадки кажутся неизбежными.

Демон supervisord не принимает недопустимый файл конфигурации. Если вы измените файл конфигурации на тот, который он не может выполнить (включая файлы журналов, которые он не может записывать), он откажется (пере)запускать и выдаст вам сообщение об ошибке, почему. Людям, которые регулярно настраивают другие демоны, такое поведение покажется типичным.

Хотя вполне возможно, что в какой-то момент может быть добавлена ​​какая-то опция для создания каталогов журналов, как обсуждалось здесь, маловероятно, что отказоустойчивое поведение изменится. Маловероятно, что мы собираемся добавить специальные случаи, чтобы игнорировать только некоторые ошибки конфигурации, как вы просите. Это означало бы, что пользователи больше не могут быть уверены, что работающий экземпляр supervisord соответствует своему файлу конфигурации.

Как я упоминал в своем первоначальном комментарии, существуют обстоятельства, при которых каталог буквально не может существовать ранее (а именно, докер в Elastic Beanstalk), потому что служба развертывания стирает главный каталог журнала во время любого нового развертывания. Такое поведение приводит к тому, что supervisord каждый раз дает сбой без какой-либо ошибки со стороны пользователя. Я не нахожу контраргументы против автоматического создания каталогов ужасно убедительными. Например:

Текущее поведение предотвращает ошибки конфигурации. В настоящее время, если в системе есть каталог /var/log/, но вы случайно ввели /var/logs/foo.txt в файле конфигурации, supervisord остановится с указанной выше ошибкой. Я думаю, что это лучше, чем закончить с /var/log/ и /var/logs/ и, возможно, не замечать этого долгое время.

Хорошо, давайте предположим, что это ошибка конфигурации. Каковы конечные последствия указанной ошибки? Полностью действительные журналы создаются и хранятся в неправильном месте. Когда кто-то ищет журналы, он не находит их там, где ожидал, поэтому они обращаются к конфигурационному файлу, видят, что назначение журнала было неправильно настроено... и исправляют его. Между тем, у них есть все предыдущие бревна, и за это время ничего не сломалось. Если что -то ломалось (допустим, работал агрегатор, который не собирал логи, потому что они были не в том месте), то могло произойти только одно из двух:

1. Служба агрегации завершается ошибкой, связанной с тем, что ожидаемые журналы не найдены (что требует расследования, которое приведет к возврату к файлу конфигурации), или:
2. Сервис агрегации не включает журналы supervisord, и в этом случае любой, проверяющий агрегатор, отмечает отсутствие журналов, а затем идет искать их вручную, обнаруживая несоответствие. Между тем, все сервисы продолжают работать , и логи были сгенерированы , поэтому их можно вручную загрузить в агрегатор без каких-либо реальных последствий.

Я не считаю аргумент pidfiles аналогичным, потому что журналы не являются критически важными, а PID. Вы вообще не можете запускать процессы без создания PID, но вы можете запускать любое приложение без создания журналов.

Я не думаю, что кто-то здесь возражает против общего безотказного поведения здесь: вместо этого мы указываем, что нынешнее отказоустойчивое поведение для файлов журналов является плохим шаблоном проектирования. Но мне кажется, что есть простое решение: включить параметр конфигурации под названием «Автоматически создавать каталог журналов, если он отсутствует?» и, если установлено значение true, запустите mkdir -p (как предлагает @dmitry-akimov-dXgjvQjNiMuVYecJ) с теми же разрешениями / владельцами, что и созданный файл журнала, и двигайтесь дальше. Вы можете установить для параметра конфигурации значение по умолчанию «false», чтобы ошибка возникала при первом прохождении несуществующего каталога журнала, поэтому пользователь был вынужден более внимательно изучить конфигурацию журнала, прежде чем принять решение.

Я не нахожу контраргументы против автоматического создания каталогов ужасно убедительными.

Большая часть обсуждений за последние пару дней, включая мои собственные ответы, была перефразированием вещей, уже изложенных в этой ветке. Я не думаю, что стоит повторять это снова, потому что я не думаю, что появляются новые точки.

Но мне кажется, что есть простое решение: включить параметр конфигурации под названием «Автоматически создавать каталог журналов, если он отсутствует?»

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

Не видел этого пару лет, но он случайно начал появляться снова.

$ sudo supervisord -c /etc/supervisor/supervisord.conf
Error: The directory named as part of the path /var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log) does not exist
For help, use /usr/local/bin/supervisord -h

Я убедился, что файл /var/log/supervisor/supervisord.log существует, и даже дал разрешение 777 для тестирования, и это все еще происходит. Есть идеи?

@sdanbury Этот билет представляет собой запрос на добавление опции для создания каталога файлов журнала. Ваша проблема отличается, поскольку вы уже создали каталог. Я открыл для него #1229.

+1

+1

Такой глупый баг и до сих пор не исправлен. Наш каталог /var/log — это tmpfs, поэтому он полностью стирается между перезагрузками.

Я действительно не понимаю, почему так много сопротивления этой идее. Tbh Я думаю, что это поведение должно быть доступно и включено по умолчанию для журналов (но я понимаю беспокойство по поводу изменения поведения по умолчанию). Однако я не вижу никаких аргументов в пользу того, чтобы он был доступен и отключен по умолчанию.

Если у меня когда-нибудь появится минутка, я мог бы рассмотреть возможность отправки запроса на включение, но на случай, если у кого-то еще возникнет желание понять это:

Вот где они выдают ошибку, если каталог не существует
https://github.com/Supervisor/supervisor/blob/b6b762d809e8c5966208b0836a9403294c3294c4/supervisor/datatypes.py#L94 -L105
https://github.com/Supervisor/supervisor/blob/b6b762d809e8c5966208b0836a9403294c3294c4/supervisor/datatypes.py#L342 -L351

Итак, началом исправления может быть:

# https://github.com/Supervisor/supervisor/blob/3e7c082a71fef3860ecf06727edd091ddb3cc282/supervisor/options.py#L635
self.create_log_directories = boolean(
    get('supervisord', 'create_log_directories', 'true')) # +++
...
section.logfile = existing_dirpath(
    get('logfile', 'supervisord.log'), 
    create=self.create_log_directories) # +-

# https://github.com/Supervisor/supervisor/blob/b6b762d809e8c5966208b0836a9403294c3294c4/supervisor/datatypes.py#L342
def existing_dirpath(v, create=False):
    nv = os.path.expanduser(v)
    dir = os.path.dirname(nv)
    if not dir:
        # relative pathname with no directory component
        return nv
    if create: # +++
        os.makedirs(dir, exist_ok=True)
    if os.path.isdir(dir):
        return nv
    raise ValueError('The directory named as part of the path %s '
                     'does not exist' % v)

# https://github.com/Supervisor/supervisor/blob/b6b762d809e8c5966208b0836a9403294c3294c4/supervisor/datatypes.py#L94
def logfile_name(val, create=False):
    coerced = val.lower() if hasattr(val, 'lower') else val

    if coerced in LOGFILE_NONES:
        return None
    elif coerced in LOGFILE_AUTOS:
        return Automatic
    return existing_dirpath(val, create=create) # +-

# https://github.com/Supervisor/supervisor/blob/3e7c082a71fef3860ecf06727edd091ddb3cc282/supervisor/options.py#L970
lf_val = logfile_name(lf_val, create=self.create_log_directories) # +-

# https://github.com/Supervisor/supervisor/blob/3e7c082a71fef3860ecf06727edd091ddb3cc282/supervisor/options.py#L426
self.add("logfile", "supervisord.logfile", "l:", "logfile=",
         lambda v: existing_dirpath(v, create=self.create_log_directories),
         default="supervisord.log")

Я сам создал путь журнала
но супервизор не создает файл журнала

~~ помощь

Tbh Я думаю, что это поведение должно быть доступно и включено по умолчанию для журналов (но я понимаю беспокойство по поводу изменения поведения по умолчанию). Однако я не вижу никаких аргументов в пользу того, чтобы он был доступен и отключен по умолчанию.

Мы, вероятно, не стали бы менять значение по умолчанию (по крайней мере, без изменения основной версии). Эта проблема была открыта в течение долгого времени, и было много комментариев с просьбами об этом, поэтому на данный момент мы хотели бы добавить ее в качестве опции (это было указано выше), но в настоящее время над ней никто не работает. В этом трекере задач, которые были отклонены, закрываются. Вопросы, которые остаются открытыми, считаются нерешенными.

Эта ветка молчала в течение минуты, но, поскольку проблема все еще открыта, я полагаю, что комментарии по-прежнему приветствуются.

Я согласен с @mnaberez и другими, которые говорят, что изменение поведения по умолчанию — это не то, что нужно делать. И отказоустойчивый подход является хорошим - очень однозначным - но явно существуют ситуации, когда это проблема конкретно для несуществующих каталогов, поскольку иногда нет никакого способа обойти это. В качестве примера упоминались среды Docker, использующие супервизор, и именно эта ситуация привела меня сюда сегодня.

Предложение @willmcgugan , на мой взгляд, хорошее; он не изменяет какие-либо существующие или стандартные поведения, поэтому он совместим с любыми конфигурационными файлами, которые могут существовать сегодня. Не уверен, думаю ли я, что должна быть рекурсивная опция или она должна просто предполагать mkdir -p, если она создает каталоги. Я склоняюсь к последнему.
Право собственности может быть установлено для пользователя: группа , под которой запускается процесс ведения журнала, будь то сам супервизор или дочерний элемент. Я думаю, что документирования того, что созданные каталоги будут иметь права доступа 775 или 755, будет достаточно.

Что касается вопросов о том, должен ли супервизор также создавать каталоги для pids и т.п. - я думаю, что это можно рассматривать как отдельный вопрос, хотя любое решение, принятое здесь, безусловно, может быть применено в другом месте. Возможно, даже это просто станет глобальным вариантом; будет ли супервизор создавать каталоги там, где это необходимо, или нет?

Все, что нужно сказать - еще одно запоздалое голосование в пользу этой функции.