Supervisor: Não foi possível especificar o proprietário ou as permissões do arquivo de log

Aparentemente o problema é que no modo AUTO os arquivos de log são criados com mkstemp, que tem permissões muito restritivas por padrão. Se você especificar o arquivo de log stdout/stderr explicitamente, os arquivos de log serão criados com as permissões esperadas.

Eu especifiquei os arquivos stdout/stderr explicitamente, eles ainda usam o usuário root em vez do especificado no programa conf.

O mesmo aqui, e o umask é sempre x77, então os arquivos de log são criados pelo root com 600 e não são legíveis por outros, isso é um problema para mim

Eu tenho em supervisord.conf :

[supervisord]
logfile=/var/log/supervisord/supervisord.log
user=supervisor
umask=022

e em conf.d/foo.conf :

stdout_logfile=/var/log/supervisord/%(program_name)s-stdout.log
stderr_logfile=/var/log/supervisord/%(program_name)s-stderr.log

O diretório /var/log/supervisord está presente e pertence a supervisor . Isso resulta em 3 arquivos de log:

-rw-r--r-- 1 supervisor supervisor   0 2013-02-20 19:26 foo-stderr.log
-rw-r--r-- 1 supervisor supervisor  82 2013-02-20 19:29 foo-stdout.log
-rw-r--r-- 1 supervisor supervisor 649 2013-02-20 19:29 supervisord.log

Não para mim, tentei isso na seção [supervisord] e em cada arquivo conf.d/* para cada processo a ser iniciado, sem sucesso, o supervisord continua criando arquivos de log com 600 perms. Parece funcionar para o arquivo de log principal supervisord.log, que parece honrar meu parâmetro umask

Eu tenho um problema semelhante. Eu configurei uma umask 000 no SV e no nível do processo, no entanto, todos os arquivos de log são criados com uma máscara de 022.
(Eu não uso o modo AUTO)
(Também tenho o problema do arquivo de log do supervisor)

Relacionado: #312, solicitando uma opção para definir o proprietário do log.

Alguma resolução para isso?

oh supervisor.

Apenas mais um usuário procurando exatamente a mesma coisa!

Definir user=<user> no programa supervisord funciona para mim... Todos os logs são enviados para esse usuário pelo supervisord.

+1 por favor - isso é muito importante

Nós também estávamos lutando com isso. A solução alternativa que encontramos envolve a pré-criação de todos os arquivos de log como parte de nosso processo de implantação antes do reinício de supervisord . Basicamente, executamos um comando grep | awk | xargs (touch ; chown; chmod) nas configurações do supervisor. Isso funciona bem desde que os logs não girem, o que raramente acontece.

Uma solução melhor seria apreciada embora. ;)

+1
Como o @gkertai mencionou, também temos que fazer muito provisionamento e verificação dupla em nosso processo de implantação para poder usar o supervisor (como pré-criar arquivos de log com permissões corretas), e isso realmente parece complicado. Isso inclui ter que garantir que os principais diretórios de arquivos de log existam ( https://github.com/Supervisor/supervisor/issues/120 ), apenas para que o supervisord comece a executar qualquer coisa ou não desative vários processos com isso. Eu realmente gosto da ideia do Supervisor e detesto a ideia de ter que manter os scripts Upstart ou initd, mas usar o Supervisor em um ambiente de produção até agora não provou ser tão confiável quanto gostaríamos. O manuseio mais limpo de arquivos de log ajudaria muito, e seria muito apreciado, _especialmente_ a criação do diretório principal do arquivo de log (posso entender não criar diretórios de log de programa, mas sinto sinceramente que o diretório de log principal do próprio supervisord deveria ser seu responsabilidade). No mínimo, sinto que ele deve retornar a um local de log padrão que deve estar sempre acessível (por exemplo /tmp/supervisord.log ) para que as mensagens de aviso sobre a falta de existência do diretório de log desejado sejam facilmente acessíveis

Para mim, a melhor solução foi alterar o umask no processo pai:

#!/usr/bin/env bash

umask 0000
supervisord -c supervisord.conf

O processo filho herdará a umask do processo pai, como resultado, todos os arquivos que serão criados terão as boas permissões:

Você também pode definir o umask usando a opção umask= na seção [supervisord ] do arquivo de configuração.

@sidnei deve haver um chmod depois mkstemp aqui ?

problema semelhante aqui, louco isso ainda não foi resolvido

[programa:teste1]
usuário = usuário1
stdout_logfile = user1.log

inicia corretamente o aplicativo como user1, mas cria user1.log como root
em vez de user1, isso parece mais um bug do que um aprimoramento

E +1 de mim.
Parece que é um bug, pois não espero que, se você especificar o usuário no programa: os arquivos de log da seção x , sejam criados a partir da raiz.

oh, a diversão de marcar com +1 um problema não resolvido de 3 anos.

:choro:

+1

Sim por favor! +1

+1 - ocorreu a rotação de log e uma série de serviços foram exibidos com erros de permissão nos identificadores de arquivo de log .. e com certeza os novos e brilhantes arquivos de log são de propriedade do root. Surpresa desagradável!

+1

+1

É triste ver tantas pessoas recorrendo a soluções desajeitadas. O nginx lida com isso muito bem.
+1

:'(

:+1:

+1

+1. Acho que ninguém vai consertar isso.

@coleplx continue com +1. Se isso não for consertado, pelo menos criaremos uma boa comunidade aqui ^_^

+1

+1

Oi pessoal,
você pode executar seu comando da seguinte forma:

command= bash -c "seu_comando first_param second_param 2> error_file.txt > stdout.txt"

e REMOVER estas tags:

redirect_stderr
stderr_logfile
stdout_logfile

@BahmaniAlireza : claro que podemos. mas então vamos perder esses recursos de guloseimas... :(
stderr_logfile_maxbytes
stderr_logfile_backups
stderr_capture_maxbytes

+1

+1

+1

Quando isso vai ser resolvido????

Quando isso vai ser resolvido????

quando incomoda alguém o suficiente para que eles não trabalhem em torno disso externamente e
eles enviam um PR... :)

+1

+1

Descobri que usar setgid parece ser um método decente de obter algumas das funcionalidades que queremos ver do parâmetro umask (não funcional) no supervisor. No meu caso eu precisava que os logs dos programas gerenciados pelo supervisor fossem visíveis para um agregador de logs, então usei setgid para que isso acontecesse: assim:
chmod u=rwx,go=rx,a+s /var/log/myapplogs/

Então, nas configurações do supervisor, eu só precisava definir logfile, user, pidfile, stdout_logfile, stdout_events_enabled (true), stderr_logfile, stderr_events_enabled (true), etc.

Configuração de amostra: https://gist.github.com/jpsandiego/a7927d14fc23efc0eae049d1466656b0

Para todos que deixam comentários separados para +1, polegares para cima, etc.: FODA-SE.

Sério, a seção de problemas é uma ferramenta de desenvolvedor, e tudo o que você está fazendo é irritar os desenvolvedores (e o resto de nós) enviando spam a todos nós com sua mensagem inútil. Eu realmente não entendo por que é necessário ensiná-lo sobre esse fato básico de etiqueta. Se você não tiver nada útil para adicionar, simplesmente dê um joinha no problema e siga em frente.

(Desculpe a todos por este spam, mas este problema ficou fora de controle.)

"Para todos que deixarem comentários separados para +1, polegares para cima, etc"
...
"Se você não tem nada útil para acrescentar, simplesmente dê um joinha no problema e siga em frente."

Apenas para FODA-SE de volta - as reações (que são os polegares para cima a que você está se referindo) foram adicionadas em março de 2016. https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and -comentários

Isso é quase QUATRO ANOS depois que esta edição foi iniciada. Antes desse momento no tempo (e vou notar que eu realmente não tinha notado que o recurso foi adicionado ainda) a única maneira correta e única de aprovar um problema era um comentário.

Se você não gosta de pessoas votando, FECHE O PROBLEMA. É aberto, então presumivelmente a equipe de desenvolvimento tem interesse nisso - e nós, os usuários que expressam interesse, também nos importamos.

Se você representa a equipe de desenvolvimento e sente que não é algo que será resolvido, declare isso e feche-o. Se não, cancele a inscrição. :)

Então, FODA-SE.

De fato.

Ryan foda-se

Em 01/10/17 17:18, david rastrick escreveu:
>

"Para todos que deixarem comentários separados para +1, polegares para cima, etc"
...
"Se você não tem nada de útil a acrescentar, simplesmente dê um joinha no problema e
siga em frente."

Só para FODA-SE de volta - reações (que é o polegar para cima que você está
referentes) foram adicionados em março de 2016.
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

Isso é quase QUATRO ANOS depois que esta edição foi iniciada. Antes disso
momento no tempo (e vou notar que eu realmente não tinha notado o
recurso foi adicionado ainda) a maneira correta e única de aprovar um problema
foi um comentário.

Se você não gosta de pessoas votando, FECHE O PROBLEMA. Está aberto, então
presumivelmente a equipe de desenvolvimento tem interesse nisso - e nós, o
os usuários que manifestam interesse nele também se importam.

Se você representa a equipe de desenvolvimento e sente que não é
algo que nunca será resolvido, o estado e fechá-lo.

Então, FODA-SE.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Supervisor/supervisor/issues/123#issuecomment-271686060 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAzKDJ3bty9ezBMMR8ObCeV_8hIazqPTks5rQ-edgaJpZM4AA4dF .

+1

+1

+1

+1

Em 01/12/17 06:31, Eugen Ivanov escreveu:
>

+1

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Supervisor/supervisor/issues/123#issuecomment-272115994 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAzKDKMUhFVHCN1C03WXOSUsuRSmv48Tks5rRfMMgaJpZM4AA4dF .

Olá a todos, em primeiro lugar eu não aprovo ser agressivo ao falar em fóruns, por qualquer motivo, pois todos nós merecemos respeito e é óbvio que ninguém aqui quer fazer mal, mas mostrar que esse problema afeta muitas pessoas. No entanto, @keen99 tem um ponto válido, assinei esta edição há algum tempo e toda vez que recebo uma notificação, me pergunto "uau, temos alguma notícia válida sobre isso?" mas aí eu abro e encontro um +1 😞 .

Ao clicar em inscrever-se e dar o polegar para cima no primeiro comentário da questão, na minha opinião é uma forma mais produtiva de demonstrar interesse, já que é muito mais visual para quantas pessoas têm o mesmo problema.

Dito isso, fazer +1 s não fará com que os mantenedores do projeto sejam mais rápidos com o problema, pois já temos muitos +1s e isso não foi corrigido (obviamente eles não precisam , quem for profundamente afetado é livre para abrir um pull request como em qualquer OSS). Mas, na minha opinião, isso incomoda muitos assinantes sem uma boa razão real e sem nenhum benefício.

Eu acertei isso e provavelmente não sei o que estou fazendo, mas setgid e definir umask em [supervisord] e no script init não funcionou. Provavelmente vou usar o valor mágico do syslog para as configurações do arquivo de log:
stdout_logfile=syslog stderr_logfile=syslog
E resolver as coisas de lá. Esta não é a primeira (e duvido que seja a última) vez que resolvo pessoalmente problemas de permissão para agregação de log usando apenas syslog. Funciona bem!

+1

Estamos usando supervisor em nossas máquinas para monitorar e controlar os processos. Gostaríamos de melhorar a segurança de nossas instâncias e notamos que não é possível alterar facilmente as permissões dos arquivos de log. Aqui estão as outras questões relevantes:

https://github.com/Supervisor/supervisor/issues/114
https://github.com/Supervisor/supervisor/issues/107

Alguém está trabalhando nessas questões ou relacionadas?

Que tal ter um campo de configuração global separado chamado stdout_log_user e stdout_log_permissions (da mesma forma para stderr_* ) que permitiria ao usuário especificar quem é o proprietário dos logs (por exemplo, apenas root ) e com quais permissões (por exemplo, 0o600 )?

Você também pode ter esses campos nas seções do programa para substituir o global, se necessário.

Se ninguém estiver trabalhando neste problema, nossa equipe da Parquery AG ficará feliz em ajudar e fazer um pull request. Por favor, deixe-me saber quais seriam os próximos passos.

@mristin Eu sugiro enviar um PR e usar seu próprio fork até que seja mesclado aqui .. o que pode levar algum tempo, pois parece que este projeto sofre com a falta de colaboradores ativos (não apontando o dedo, não tenho hora de entrar e contribuir também, infelizmente!).

@lukeburden , obrigado, faremos isso.

Alguns dos usuários interessados ​​no recurso poderiam confirmar rapidamente que nossa proposta seria adequada para eles?

@mristin que faria o truque no meu caso. Eu usaria as configurações de nível de programa para garantir que, quando a rotação de log acontecer no meu processo de aipo, os novos arquivos de log sejam de propriedade do usuário correto celery e que as permissões sejam apropriadas. No momento, o supervisor cria os novos arquivos de log como root e, em seguida, o processo de aipo não pode gravar no novo arquivo de log.

Meu único pensamento adicional é que pode ser uma boa ideia ter uma configuração para permitir a especificação do grupo também? Isso pode ser importante para a configuração de algumas pessoas.

@mristin isso faria o truque para mim também.

Eu também posso ajudá-lo a testá-lo se você precisar de mim.

Eu sei que isso é antigo, mas eu estava tendo dificuldade em fazer o supervisor NÃO girar os logs e, aparentemente, em algum momento, o nome da configuração para a configuração que desativa isso mudou de "logfile_maxbytes" para "stdout_logfile_maxbytes".

O que descobri para contornar a alteração das permissões do arquivo de log de volta para a raiz foi que desativar a rotação de log dos supervisores e usar o logrotate funcionou. No entanto, se os arquivos crescerem rápido o suficiente, o logrotate será acionado devido ao tamanho do arquivo.

Talvez isso ajude alguém.

Olá a todos,

Encontrei esta resposta neste tópico: http://supervisor-users.10397.x6.nabble.com/Supervisor-users-Changing-owner-of-log-files-td4945286.html

Ao criar o arquivo de log com o usuário desejado (como aquele que possui o processo filho do supervisor), a propriedade é mantida durante o processo do supervisor.

Espero que ajude!

Grande abraço e fique seguro!

@keen99 +1