O que o fantoche faz para corrigir um serviço systemctl 'preso' em que systemctl se recusaria a iniciar um serviço?

Tivemos um cenário em que no RHEL não podíamos iniciar um aplicativo que estava em execução e acabamos de parar.

sudo systemctl start myservice

Nós não tínhamos acesso aos journaldlogs neste servidor, então o estado do servidor era um mistério.

A instância do aplicativo não 'iniciava', pois registra detalhadamente e, no entanto, os logs do aplicativo não foram tocados.

Meu amigo veio e executou uma atualização do agente de marionetes nesta caixa:

puppet agent --environment=production --test

Depois disso - poderíamos parar e iniciar o serviço.

Eu entendo que o fantoche tem a capacidade de remover e criar um serviço e também de 'recarregar daemon'. ou seja, algo como

systemctl stop [servicename]
systemctl disable [servicename]
rm /etc/systemd/system/[servicename]
systemctl daemon-reload
systemctl reset-failed

Agora estou percebendo em retrospecto que eu deveria ter corrido

sudo systemctl reset-failed

Estou tentando descobrir qual é a coisa específica que esse fantoche faz para que um serviço 'travado' funcione.

Minha pergunta é: O que o fantoche faz para corrigir um serviço systemctl 'preso' onde o systemctl se recusaria a iniciar um serviço?