Como ativo o log do launchd no OS X?

Como ativo o log do launchd no OS X 10.6?

Eu adicionei um novo daemon que não está sendo iniciado corretamente (o status é 1).

Quero depurar o problema, mas não consegui encontrar launchdlogs, eles não estão no /var/log/launchd.log.

mac-osx launchd launchctl

— sorin
fonte

Respostas:

Eu encontrei a solução

 sudo launchctl log level debug

e depois disso

 tail -f /var/log/system.log

— sorin
fonte

Eu percebi que este sistema operacional precisa de administrador, como qualquer outra coisa. Estava totalmente procurando por isso depois de um dia gritando "WTF, onde está a bandeira detalhada!" OSX é ótimo, claro, mas difícil de entender. Thx +1

— chiggsy 15/11/2010

Acompanhamento, FYI: Isso também funciona com o OS X 10.7.2. Obrigado.

— Alan W. Smith

Estou tendo problemas com meus servidores Leopard e pensei que havia algo errado com minha lista de inicialização (embora a mesma lista funcione no Snow Leopard). Aconteceu de eu tropeçar nesta e funciona como charme :)

— icasimpan

Isso não funciona mais desde as 10.10 Yosemite. Versão do launchctl: Darwin System Bootstrapper 2.0.0: Ter 9 de setembro 16:30:56 PDT 2014

— JeanMertz

@JeanMertz - alguma alternativa?

— Umang

Supondo que você esteja tentando registrar seu processo em vez de iniciar o próprio, se você incluir as seguintes linhas no arquivo launchd plist:

<key>StandardOutPath</key>
<string>/path/to/logfile.log</string>
<key>StandardErrorPath</key>
<string>/path/to/another_logfile.log</string>

e recarregue o processo, qualquer registro ou impressão interna do seu script será capturado em um desses dois arquivos sempre que for executado. embora a rotação dos arquivos pareça depender de você. como seria de esperar, se você usar o mesmo arquivo nas duas instâncias, ele registrará o erro e o stdout no mesmo local.

Consulte: Depurando a seção jobs do launchd em Criando Daemons e Agentes de Inicialização .

— Pedro
fonte

No OS X 10.11 (El Capitan), você pode sudo launchctl debug <service-target> --stdout --stderrativar o registro único, se não quiser usar a opção de sistema de arquivos sugerida pelo @peter.

Muitas coisas são diferentes na implementação atual de launchctl, e isso <service-target>é meio estranho. Por exemplo, suponha que eu tenha um serviço local que eu configure em ~/Library/LaunchAgents/dev.localmon.plist, que tenha o "rótulo" dev.localmon. Sua <service-target>é gui/$UID/dev.localmon, onde $UIDé o seu ID de usuário, que, uma vez que você está executando isso no CLI, o seu shell interpolará para você.

Então, supondo que meu dev.localmonserviço estivesse travando na inicialização (era), eu poderia chamar o seguinte para launchctlinserir o stdout e o stderr do processo no meu shell na próxima vez (e somente na próxima) que o serviço for iniciado:

sudo launchctl debug gui/$UID/dev.localmon --stdout --stderr

Como isso ocorre com os TTYs abertos e prontos, vá para outro terminal e execute:

launchctl start dev.localmon
# start is a legacy command and doesn't use the fancy new service-target notation

Então, de volta ao primeiro terminal, você deverá ver a saída. (Estranhamente, ele não fecha quando o processo do serviço morre, então você deve pressionar Ctrl-C.)

Btw, depois de corrigir seu arquivo de configuração com qualquer PATH ou ambiente que esteja quebrando o serviço antes, você ainda precisará usar as launchctl unload ~/Library/LaunchAgents/dev.localmon.plist && launchctl load ~/Library/LaunchAgents/dev.localmon.plistduas etapas antigas , pois o suposto uncachesubcomando da documentação tem o seguinte efeito:

O comando ainda não foi implementado.

Yay para a estratégia de lançamento pós-Jobs da Apple: "Mova-se rápido e quebre coisas"

— chbrown
fonte

sudo launchctl debugsai Could not find domain forcomigo

— Tom