Estou um pouco confuso sobre como os trabalhos iniciam nos eventos do Upstart. Para ilustrar meu mal-entendido, tenho quatro trabalhos do Upstart que parecem com os seguintes:
Job 1:
start on local-filesystems
task
script
echo "job 1 ran" >> /tmp/job1
end script
Job 2:
start on (local-filesystems and net-device-added)
task
script
echo "job 2 ran" >> /tmp/job2
end script
Job 3:
start on (local-filesystems and bluetooth-device-added)
task
script
echo "job 3 ran" >> /tmp/job3
end script
Tarefa 4:
start on local-filesystems or (local-filesystems and net-device-added) or (local-filesystems and bluetooth-device-added)
task
script
echo "job 4 ran" >> /tmp/job4
end script
Espero o seguinte conteúdo de arquivo após uma reinicialização:
/ tmp / job1:
job 1 ran
/ tmp / job2
job 2 ran
/ tmp / job3
job 3 ran
/ tmp / job4
job 4 ran
job 4 ran
job 4 ran
Espero que o Job 4 tenha sido executado três vezes, porque ele pode ser iniciado por três conjuntos separados de eventos, todos ocorridos conforme comprovado pelos outros jobs. Mas minhas expectativas estão incorretas; os arquivos realmente contêm o seguinte:
/ tmp / job1:
job 1 ran
/ tmp / job2
job 2 ran
/ tmp / job3
job 3 ran
/ tmp / job4
job 4 ran
Por que o job4 só é executado uma vez, mesmo que os três conjuntos de eventos estejam ocorrendo? Existe alguma maneira de obter o comportamento de executar este trabalho sempre que algum dos sinais ocorrer, independentemente de quantas vezes o trabalho realmente é executado? Se isso ajudar, eu o editei para imprimir a variável $ UPSTART_EVENTS para ver quais eventos estão causando o job 4 e seus sistemas de arquivos locais.
Para resumir: gostaria que o job 4 fosse executado no evento local-filesystems, E no evento net-device-added (desde que local_filesystems também tivesse ocorrido), E no evento bluetooth-device-added ( desde que tenha ocorrido local_filesystems). Como faço isso acontecer?
Obrigado!
start on Altera apenas a meta da tarefa para iniciar a partir da parada. Se o trabalho já estiver em start , o trabalho não será retido e não fará nada com os eventos iniciados.
Se você quiser que ele seja executado várias vezes, você pode adicionar:
instance $UPSTART_EVENTS
Com esse upstart, será executada uma instância do trabalho para cada par de eventos correspondido em start on .
A solução óbvia, apesar de deselegante, é criar 3 trabalhos diferentes para iniciantes. Você apenas usaria os trabalhos 1-3 criados acima. Eu olhei para isso alguns em uma VM e isso é o melhor que eu poderia inventar. Eu alguém tem uma solução mais elegante que eu adoraria ver.
A resposta é bem simples: você não pode responder a vários eventos se o trabalho já estiver sendo executado em nome de qualquer uma dessas condições . O Upstart não grava e reproduz eventos. Se o seu trabalho estiver sendo executado devido ao evento A e o evento A for iniciado, ocorrerá o evento B, ao qual o mesmo trabalho também poderá responder. Não há fila que salve o evento B e o reproduza em todos os trabalhos que estavam sendo executados anteriormente para avaliar o dito evento novamente. Afinal de contas, isso é init, e o objetivo dos scripts init geralmente é executar uma vez.
O bootchart mostrará prontamente quais sinais são emitidos simultaneamente.
Você mesmo pode verificar isso configurando seu trabalho para responder a um evento, fazendo com que ele faça algo simples, como sleep 30s, e enquanto o job estiver rodando, emita outro evento (initctl emit foo). Quando o trabalho terminar a primeira execução, ele não será executado novamente.
"Para resumir: gostaria que o job 4 fosse executado no evento local-filesystems, E no evento net-device-added (desde que local_filesystems também tivesse ocorrido), E no evento adicionado com dispositivo bluetooth (desde que tenha ocorrido local_filesystems). Como faço isso acontecer? "
Realiza este tipo de execução condicional claramente. Isso não significa, porém, que será executado mais de uma vez. Você pode reconsiderar a solução deste problema desta maneira para começar.