Como registrar um agente com o launchd

Question

Não consigo agendar um lançamento periódico com launchctl / launchd no OS X (Leopard). Basicamente, não consigo encontrar uma lista passo a passo de instruções na Web e a abordagem intuitiva não funciona.

O arquivo sync.plist :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>Label</key>
        <string>net.madrat.utils.sync</string>
        <key>Program</key>
        <string>rsync</string>
        <key>ProgramArguments</key>
        <array>
            <string>-ar</string>
            <string>/path/to/folder/</string>
            <string>/path/to/backup/</string>
        </array>
        <key>StartInterval</key>
        <integer>7200</integer>
    </dict>
</plist>

Eu coloquei este script dentro do caminho ~/Library/LaunchAgents .

Em seguida, eu registrei o script usando

launchctl load ~/Library/LaunchAgents/sync.plist

Finalmente, para testar se funciona, iniciei o trabalho:

 launchctl start net.madrat.utils.sync

- Nada aconteceu. A execução manual do comando rsync no terminal produz o resultado esperado.

Tenho quase certeza de que o trabalho foi registrado corretamente porque, se eu tentar iniciar um trabalho não existente, recebo uma mensagem de erro (que eu não obtive no comando acima) .

O que eu fiz de errado?

    

Answer 1

O

Lingon é uma boa ferramenta de GUI para gerenciar o launchd. O projeto parece não ter suporte agora ... mas definitivamente ainda funciona no 10.5.x.

Mas para o seu problema específico ... você já tentou

sudo launchctl list 

Isso lhe dirá se o .plist está disparando corretamente. Ele retornará 1 se o daemon não for lançado e um '0' se for bem-sucedido. Talvez procure por isso.

Sempre que vejo um '1', geralmente é porque coloquei o script no lugar errado, cometi um erro de digitação ou configurei as permissões incorretamente.

Também .... reinicie com frequência .. Eu vi

launchctl start

não será eficaz quando houver uma reinicialização ..

Além disso, ao olhar para sua pergunta mais de perto ... por que não apenas colocar esse código rsync em um script bash ... e colocá-lo em /usr/bin/ ..... Então você poderia apenas chmod+x desse arquivo .... e simplifique o seu .plist para disparar esse script sempre que quiser ...

    

Answer 2

Resposta longa:

É difícil trabalhar com o launchd sem entender alguns princípios básicos. Portanto, é provável que você não encontre instruções passo-a-passo, pois possui muitos recursos. Uma boa jogada é dirigir-se ao guia de primeiros passos no ADC: link

Você também pode ler as man pages para launchd , launchctl e a sintaxe dos arquivos .plist, launchd.plist .

Há um mal-entendido frequente sobre onde colocar seu agente ou deamon, então deixe-me enviar algumas informações sobre isso aqui:

• Se o seu trabalho precisar ser executado mesmo quando nenhum usuário estiver conectado, coloque-o em / Library / LaunchDaemons.
• Se for útil apenas quando os usuários estiverem conectados, coloque-os em / Library / LaunchAgents ou nos diretórios pessoais do LaunchAgents de usuários específicos (~ / Library / LaunchAgents).
• Não coloque seu trabalho em / System / Library, que é reservado para daemons fornecidos pelo sistema.

~/Library/LaunchAgents         Per-user agents provided by the user.
/Library/LaunchAgents          Per-user agents provided by the administrator.
/Library/LaunchDaemons         System wide daemons provided by the administrator.
/System/Library/LaunchAgents   Mac OS X Per-user agents.
/System/Library/LaunchDaemons  Mac OS X System wide daemons.

Resposta curta:

O nome do seu arquivo plist pode estar errado, não pode testar agora, mas eu teria configurado para net.madrat.utils.sync.plist . Também pode ser útil primeiro unload seu deamon antes de carregá-lo se você editou o arquivo.

    

Answer 3

Não consigo encontrar documentação de que esse seja um comportamento padrão, mas parece que o launchd requer caminhos absolutos em arquivos plist. Então, tente /usr/bin/rsync . Funciona para mim!

    

Answer 4

tente isso, meus scripts funcionam sem usar a parte do programa, apenas args do programa ...

substituir

    <key>Program</key>
    <string>rsync</string>
    <key>ProgramArguments</key>
    <array>
        <string>-ar</string>
        <string>/path/to/folder/</string>
        <string>/path/to/backup/</string>
    </array>

com

    <key>OnDemand</key>
    <true/>
    <key>ProgramArguments</key>
    <array>
        <string>rsync</string>
        <string>-ar</string>
        <string>/path/to/folder/</string>
        <string>/path/to/backup/</string>
    </array>

    

Answer 5

tente adicionar essas chaves ao seu arquivo plist

    <key>KeepAlive</key>
    <true/>
    <key>RunAtLoad</key>
    <true/>

    

Answer 6

Você tem uma coisa errada em seu arquivo .plist e uma coisa desonesta (cada um desses pontos foi abordado em respostas anteriores; estou reunindo-os aqui).

Seria melhor escrever:

<key>ProgramArguments</key>
<array>
  <string>/usr/local/bin/rsync</string>
  <string>-ar</string>
  <string>/path/to/folder/</string>
  <string>/path/to/backup/</string>
</array>

O primeiro argumento na matriz ProgramArguments é o programa a ser executado - você omitiu isso. Se a chave Program for omitida, o padrão será o primeiro argumento de ProgramArguments ; provavelmente é sábio especificar isso apenas uma vez.

Como você omitiu esse primeiro argumento, seu .plist irá invocar o rsync (através do nome em Program ), mas o 'primeiro argumento' do rsync teria sido /path/to/folder e não -ar (o programa em execução terá sido brevemente visível em ps output, antes de sair com um erro, mas nomeado como -ar , que é o conteúdo do argumento zeroth).

Você não tem para incluir o caminho para rsync , mas neste tipo de contexto, é provavelmente prudente fazê-lo, para evitar ter que depender do PATH sendo definido apropriadamente.

A documentação para isso está em launchd.plist(5) . Observe que essa página de manual enfatiza que o valor da chave ProgramArguments é passado para execvp(3) . É a página execvp que explica sobre a pesquisa PATH.