Por que 'systemctl stop service' não pode invocar o serviço?

Question

vim /home/mytest.sh
rm -f /home/mytest/*

Eu quero escrever um serviço para executar a ação remover.
Minhas expectativas:
sudo systemctl stop mytest pode excluir arquivos em / home / mytest
sudo systemctl start mytest do nothing.

Edite meu arquivo de serviço.

sudo vim /etc/systemd/system/mytest.service
[Unit]
Description=delete file

[Service]
Type=oneshot
ExecStart=/bin/true
ExecStop=/bin/bash /home/mytest.sh

[Install]
WantedBy=multi-user.target

Ativar.

sudo systemctl enable mytest

Agora eu encontrei uma ação estranha para o meu melhor serviço.

sudo systemctl start mytest pode excluir arquivos em / home / mytest
sudo systemctl stop mytest do nothing.

Por quê? Os fundamentos dão uma explicação detalhada.

    

Answer 1

Isso é explicado em detalhes em a documentação do serviço systemd , mas você praticamente preciso ler tudo isso para entender o que está acontecendo. A parte mais pertinente neste caso é o exemplo 3; a partir disso, o leitor pode obter um serviço personalizado, já que você declarou que ele nunca fica ativo, portanto, sua ação de interrupção será executada assim que a ação de início for concluída.

Para conseguir o que você procura, você precisa de um serviço personalizado que, no entanto, se torne ativo:

[Unit]
Description=delete file

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStop=/bin/bash /home/mytest.sh

[Install]
WantedBy=multi-user.target

    

Answer 2

Basicamente, systemd monitora todos os processos iniciados por meio de cgroups e, a menos que você especifique RemainAfterExit=yes , não manterá as informações de estado "sim, mytest.service foi executado e deve ser considerado ainda ativado embora haja nenhum processo deixado em seu cgroup. "

Sem RemainAfterExit=yes , systemctl stop mytest faz systemd dar uma olhada no systemd/system.slice/mytest.service cgroup, e como não há processos nele, ele simplesmente pensa "parece que já está parado, então ... nada para fazer lá! "