Execute uma atualização *uma* vez no desligamento – systemd-run?

Este comando baseia-se numa extrapolação e adaptação para o caso em questão de uma resposta minha no Ask Ubuntu, que converti em systemd-runcomando. A resposta extrapolada e adaptada, útil para compreender o raciocínio por trás do comando e útil para configurá-lo como serviço permanente e não como uma unidade transitória, é relatada abaixo.

Observe que isso será executado no desligamento e não na reinicialização . Isso é intencional. Se isso for indesejado e você quiser executá-lo ao desligar e reinicializar, simplesmente substitua a ExecStoppropriedade por apenas dnf5 update -y package1.

systemd-run \
    --property="ExecStop=sh -c 'systemctl list-jobs | grep -q \"poweroff.target.*start\" && dnf5 update -y package1'" \
    --property=RemainAfterExit=true \
    --property=TimeoutStopSec=infinity \
    --property=After=network-online.target \
    true

Substitua package1de acordo com as necessidades.

O que minha pesquisa me ensinou é que:

1. É difícil travar o serviço no ponto certo na cadeia de desligamento/reinicialização se você estiver abordando o problema em termos de "ordem em que os serviços são desativados na cadeia de desligamento/reinicialização"; há muito para acompanhar. O truque aqui é abordar o problema em termos de "ordem em que os serviços sobem na cadeia de inicialização" e travar um oneshotserviço logo após network-online.targetter subido, ao mesmo tempo marcando-o como ativo, usando RemainAfterExit=truee fornecendo-lhe um ExecStopação que será acionada "naturalmente" quando o sistema cair, logo antes da rede cair.
2. Não há uma maneira superlimpa de determinar se o sistema está desligando ou reinicializando; no entanto, isso pode ser feito de forma confiável, verificando quais alvos especiais do systemd estão ativos durante a sequência de desligamento/reinicialização ; neste caso, poweroff.targetestará ativo apenas caso o sistema esteja desligado para desligar.

Então, juntando tudo, isso poderia ser feito criando um serviço /etc/systemd/system/update.service(o nome do arquivo e os campos Descriptione ExecStop, é claro, podem ser ajustados; certifique-se de que o arquivo seja de propriedade root:roote tenha 644/ -rw-r--r--permissões):

[Install]
WantedBy=multi-user.target

[Service]
ExecStop=sh -c 'systemctl list-jobs | grep -q "poweroff.target.*start" && dnf5 update -y package1'
RemainAfterExit=true
TimeoutStopSec=infinity

[Unit]
After=network-online.target
Description=update

Uma vez feito isso, execute sudo systemctl enable --now update.servicepara habilitar o serviço.

TimeoutStopSec=infinityé obviamente necessário no caso de uma atualização, mas pode ser alterado caso você queira usá-lo para outra coisa.

Pedi a @TomYan para converter seu comentário em uma resposta; infelizmente, eles não o fizeram e então minha recompensa vai cair por terra. De qualquer forma:

Uma abordagem aqui é explorar o fato de que as unidades podem ter comandos que são executados na saída; então, um serviço com

• Type=oneshot
• um fictício ExecStart(como /usr/bin/true) (ou nenhum se especificado através do arquivo de unidade)
• RemainAfterExit=true(para marcá-lo como ainda vivo mesmo que o manequim tenha saído)
• ExecStop=que executa o comando que eu preciso
• After=network.targetpara garantir que esta unidade seja parada antes que a rede seja parada (especifica que deve ser iniciada depois, mas parada antes)

deve funcionar e ser interrompido no desligamento se for iniciado uma vez.

Percebi que o tempo limite de parada pode ser um problema, mas não é mais um problema tão ruim, porque a partir do systemd 188 é possível configurar TimeoutStopSec=um serviço.

Para uma atualização única , tente um at-job.

De outra forma:

Para sistemas do tipo Debian, instalar e configurar unattended-upgradesseria o caminho a percorrer. Oferece a opção de instalação no desligamento.

O equivalente do Redhat seria dnf-automatic.

Ambos fazem uso de temporizadores do systemd.

Se você não quiser atualizar pacotes específicos, você pode fixá-los/segurá-los.