Existe alguma estratégia para *realmente* desabilitar os serviços do systemd? Alguns iniciam mesmo depois de desabilitar com systemctl

"Desabilitar" um serviço no systemd é basicamente equivalente a "remover do nível de execução" em outros sistemas init (remove o serviço da árvore de dependência 'multi-user.target'). Na maioria das vezes, isso significa que o serviço não será mais iniciado explicitamente durante a inicialização.

Mas isso não significa que o serviço não possa ser iniciado de outrassystemctl start maneiras – por exemplo, você ainda pode desativar manualmente um serviço, assim como /etc/init.d/foo startno passado.

Alguns serviços são configurados para serem iniciados de maneiras mais indiretas do que simples "na inicialização", mas que ainda podem acionar sua inicialização enquanto o sistema ainda está inicializando:

• Eles podem ser iniciados como uma dependência explícita de algum outro serviço. Se esse outro serviço for iniciado na inicialização, este também será iniciado.

  Tente systemctl list-dependencies --reverse <unit>ver se algo quer ou requer esse serviço.

• Eles podem ter uma .socketunidade associada que iniciará o serviço "sob demanda" assim que um cliente tentar se conectar. (Se houver uma tentativa de conexão durante a inicialização, certamente parecerá que o serviço foi iniciado "na inicialização".)

  O serviço systemctl statusdeve mostrar se está ativado por uma unidade de soquete ou timer – essas unidades também podem ser interrompidas e desabilitadas.

• Da mesma forma que a ativação de soquete sob demanda, os serviços podem ser "ativados por D-Bus" por um programa tentando falar com eles através do barramento de mensagens. (Por exemplo, é possível que o packagekitd seja iniciado porque o gnome-software tentou consultá-lo no momento do seu logon.)

  Muitas vezes, esses serviços têm um Alias ​​que "systemctl disable" remove, impedindo a ativação indesejada do D-Bus de um serviço desativado - mas isso nem sempre é implementado corretamente. ¹

No entanto, além disso, o systemd não ativa automaticamente as unidades que você desativou. Se você ver que uma unidade está explicitamente habilitada novamente (por exemplo, o link simbólico dentro multi-user.target.wantsfoi recriado), então ela deve ter sido acionada por algo externo.

• Algumas distribuições usam predefinições do systemd para reativar ou reativar unidades de acordo com sua política geral, invocando systemctl presettoda vez que algum pacote relevante é atualizado. (Consulte a página de manual systemd.preset .) Se você criar uma predefinição personalizada que diga ao systemctl para sempre desabilitar o serviço, ele substituirá a política da distribuição:

  (/etc/systemd/system-preset/00-steve.preset)
  
  disable packagekit*.service
  

• Algumas distribuições têm uma chamada direta para systemctl enablehardcoded em seus scripts de pós-atualização. Nesse caso, mascarar a unidade faria com que o systemd se comportasse como se não existisse – ele não pode mais ser ativado, iniciado ou tocado de outra forma:

  % systemctl disable --now packagekit
  % systemctl mask packagekit
  

  O gerenciador de pacotes da sua distribuição também pode ter a opção de pular a extração de certos arquivos completamente, para que eles literalmente não existam mais no que diz respeito ao systemd – por exemplo, pacman:

  (/etc/pacman.conf)
  
  [options]
  NoExtract = usr/lib/systemd/system/packagekit*
  

Ativação do D-Bus

¹ Se o seu serviço estiver listado em busctl --activatable, tente usar, por exemplo, busctl treeem seu nome de barramento e veja se isso faz o serviço iniciar.

Se falar com org.freedesktop.PackageKit1 (ou qualquer outro nome) fizer com que um serviço systemd desabilitado seja iniciado, isso geralmente significa que o .servicearquivo D-Bus está apontando para o .servicearquivo systemd errado (sim, são coisas diferentes), ou não apontando para um serviço systemd (fazendo com que o dbus-daemon gere o serviço diretamente).

No primeiro caso, você pode mascarar o systemd .service e o dbus-daemon não poderá mais iniciá-lo. Neste último caso, você terá que sobrescrever o D-Bus .service via /usr/local/share/dbus-1ou fazer com que seu gerenciador de pacotes não o extraia (já que dbus-daemon não tem um equivalente para habilitar/desabilitar, nem mascarar/desmascarar) .

Como eu odeio quando coisas assim acontecem, eu desinstalo o aplicativo e destruo a mídia de instalação para que não possa ser reinstalado.

De jeito nenhum eu vou manter aplicativos que não me dizem tudo o que eles fazem, eles podem incluir a instalação de outras coisas desconhecidas, como trojans ou um backdoor, em seu sistema que eles também não mencionam.

Eu o desinstalaria para garantir que eles não pudessem fazer uma atualização para anular sua solução alternativa. Quando o aplicativo não existe, as atualizações também não.