Início / server / Perguntas / 953093
Accepted
anx
Asked: 2019-02-09 19:52:53 +0800 CST

Por que o systemd rejeita o nome da minha unidade como 'nem um ID de invocação válido nem um nome de unidade'?

  • 772

Eu preciso substituir o ExecStartparâmetro de um modelo systemd . Confirmei que o arquivo de unidade existe e passa na validação. Adicionar um [email protected]/override.confarquivo funciona bem em algumas máquinas:

user@prod-west-1604$ systemctl --version | head -1
systemd 229
user@prod-west-1604$ file -b /etc/systemd/system/[email protected]
symbolic link to /lib/systemd/system/nginx.service

user@prod-west-1604$ sudo systemctl edit [email protected]
# (opens editor as expected)

No entanto, em máquinas que executam versões mais recentes do systemd, a operação falha:

user@prod-east-1810$ systemctl --version | head -1
systemd 239
user@prod-east-1810$ file -b /etc/systemd/system/[email protected]
symbolic link to /lib/systemd/system/nginx.service

user@prod-east-1810$ sudo systemctl edit [email protected]
Failed to get the load state of [email protected]: Unit name [email protected] is neither a valid invocation ID nor unit name.

Por quê ?

systemd

2 respostas

  1. Best Answer

    Isso é causado por um bug do systemd introduzido na v233 e corrigido na v240 . Não é necessário atualizar o systemd , na maioria dos casos systemctl edité pouco mais que um atalho para o seguinte:

    sudo mkdir -p /etc/systemd/system/[email protected]/
sudo vim /etc/systemd/system/[email protected]/override.conf

    Os arquivos de substituição funcionarão, mesmo nas versões systemdsystemctl edit em que o comando não funciona. Não se esqueça de aplicar a nova configuração usando:

    sudo systemctl daemon-reload
    • 3

  2. Recebi a mesma mensagem de erro sobre ' nem um ID de invocação válido nem um nome de unidade ' ao iniciar um serviço com falha, mas a correção foi diferente da resposta aceita e não relacionada ao bug. A mensagem de erro foi um arenque vermelho total e um desperdício de tempo, como explico abaixo.

    Meu problema foi com o serviço systemd netfilter-persistent. A mensagem de erro me levou a acreditar que havia um problema com o systemd-gears iniciando o serviço. Então eu tive uma epifania: E se houvesse uma iptablesregra duff em " rules.v4 " o serviço chamado?

    Sim: o serviço não estava iniciando por causa de um arquivo dependente necessário para aumentá-lo, neste caso " rules.v4 " teve um erro. Isso não apareceu no systemctl statusou journalctl -xe. Uma expressão sed não correspondeu e substituiu um espaço reservado por uma sub-rede. Uma vez que o arquivo de regras foi construído corretamente, o serviço subiu corretamente.

    Ao investigar essa mensagem de erro, não fique tão preocupado olhando para a própria definição de serviço do systemd que você não revise nenhum arquivo dependente sendo chamado que possa estar com erro de erro.

    De qualquer forma, espero que isso evite que outros persigam o rabo com esta mensagem de erro.

    • 1

relate perguntas