Eu assumo que, ao "acionar" um serviço que você quer que um novo serviço comece a rodar (que é algo que o systemd pode fazer) em vez de fazer um serviço já em execução fazer algo (que é completamente fora do alcance do sistema init).
Noções básicas do D-Bus
Cada mensagem D-Bus tem exatamente um campo 'destinatário' (que pode ser um nome bem conhecido, como org.example , um nome exclusivo, como :1.234 , ou o endereço de broadcast).
Os sinais D-Bus (enviados para publicar eventos que já aconteceram) são geralmente transmitidos para o barramento inteiro, então eles não podem fazer com que nenhum serviço seja iniciado. Se você está pensando em mensagens unicast enviadas para um serviço específico , elas geralmente são chamadas_de_todos, não sinais.
Autostart do serviço D-Bus
O daemon de barramento iniciará automaticamente os serviços quando:
- há uma mensagem enviada para um nome conhecido e específico,
- e esse serviço conhecido não é "reivindicado" no momento no ônibus,
- e esse nome conhecido tem um arquivo de serviço D-Bus correspondente (não confundir com arquivos systemd .service) em
/usr/share/dbus-1/system-services/.
É importante observar no ponto 2 que apenas um serviço pode reivindicar um nome conhecido e receber mensagens destinadas a esse nome. Contanto que o verdadeiro systemd-hostnamed já esteja em execução e tenha reivindicado org.freedesktop.hostname1 , ele receberá essas mensagens - outros processos não podem fazer o mesmo.
O mesmo ponto # 2 também significa que o autostart não acontecerá para nomes que um serviço está retendo atualmente. A mensagem será simplesmente entregue ao serviço já em execução.
No ponto 3, o nome do arquivo deve exatamente corresponder ao nome do barramento bem conhecido; ou seja, você não pode ter vários serviços competindo por autolaunch com o mesmo nome. Portanto, no que diz respeito ao dbus-daemon, cada mensagem só pode iniciar um serviço no máximo.
Autostart via systemd
Se o arquivo .service do D-Bus (sob / usr / share / dbus-1 /… /) contiver uma opção SystemdService= , o dbus-daemon tentará iniciar o serviço via systemd em vez de tradicionalmente bifurcar / executar qualquer está listado em Exec =.
(Muitas vezes, o serviço systemd instala um alias chamado dbus-[busname].service - esta é apenas uma convenção para permitir a ativação / desativação do systemctl, e a sintaxe não tem um significado especial além disso).
Como os serviços systemd podem ter dependências , agora você tem uma solução alternativa para a limitação "cada mensagem só pode iniciar um serviço": o serviço ativado diretamente pode atrair outros serviços como dependências. No entanto, tudo o que foi explicado antes ainda se aplica - quando o serviço 'real' estiver em execução, outras mensagens o alcançarão diretamente e não acionarão a inicialização automática.
Conclusão
Parece que você está tentando evitar systemd-hostnamed completamente, e sempre que netplan chamar o método SetHostname() do hostnamed, você quer que seu próprio programa o receba.
Isso não é possível com um script de shell simples. Você não pode receber mensagens D-Bus via stdin, nem através de variáveis de ambiente, nem através de argumentos de linha de comando. Seu script saberá apenas que foi iniciado por algum motivo, mas não fará ideia do que deveria estar fazendo exatamente.
Mas é possível em geral - contanto que você use uma linguagem de programação que tenha um módulo D-Bus. Você "apenas" precisa se conectar ao barramento do sistema, reivindicar o nome, receber mensagens e tratá-las da mesma maneira que systemd-hostnamed faz. Muitos módulos dbus vêm com exemplos "skeleton D-Bus service".
(Na verdade, já existem reimplementações de terceiros de vários daemons do systemd, por exemplo, LoginKit, systembsd, systemd-shim.)