Home / server / Questions / 953093
Accepted
anx
Asked: 2019-02-09 19:52:53 +0800 CST

Why does systemd reject my unit name as 'neither a valid invocation ID nor unit name'?

  • 772

I need to override the ExecStart Parameter of a systemd template. I have confirmed that the unit file exists & passes validation. Adding a [email protected]/override.conf file works well on some machines:

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)

However, on machines running newer systemd versions, the operation fails:

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.

Why?

systemd

2 Answers

  1. Best Answer

    This is caused by a systemd bug introduced in v233 and fixed in v240. It is not necessary to upgrade systemd, in most cases systemctl edit is little more than a shortcut for the following anyway:

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

    The override files will work, even in systemd versions where the systemctl edit command does not. Do not forget to apply new configuration using:

    sudo systemctl daemon-reload
    • 3

  2. I received the same error message about 'neither a valid invocation ID nor unit name' when starting a service failed, but the fix was different than the accepted answer and unrelated to the bug. The error message was a total red-herring and a time waster as I explain below.

    My issue was with systemd netfilter-persistent service. The error message lead me to believe there was a problem with the systemd-gears starting the service. Then I had an epiphany: What if there was a duff iptables rule in "rules.v4" the service called?

    Yup: the service wasn't starting because of a dependent file required to raise it, in this case "rules.v4" had an error. This didn't appear in the systemctl status or journalctl -xe. A sed expression failed to match and replace a placeholder with a subnet. Once I the rules file built correctly, the service rose-up correctly.

    When investigating this error message, don't get so blinkered looking at the systemd service definition itself that you don't review any dependent files being called that might be in error error.

    Anyhoo, hope this saves others from chasing their tail with this error message.

    • 1