During upgrade of Debian9 Agent we see repeated Error in the log [elastic_agent][error] failed to read service: Unit name elastic-agent is not valid.

[EricDavisX]

Testing on Debian9 7.10.2 BC Agent installed to 7.11 SNAPSHOT Cloud Kibana / stack.
when using the UI to upgrade Agent it works, but is showing an error in the log for the 10 minute 'watching' duration for some reason.

Some notes are below:

error log line:
[elastic_agent][error] failed to read service: Unit name elastic-agent is not valid.

debian-log.txt

from my debian host:
systemctl output, which looks ok:

zeus@mainqa-atlcolo-10-0-6-185:~/elastic-agent-7.10.2-linux-x86_64$ systemctl status elastic-agent
● elastic-agent.service - Elastic Agent is a unified agent to observe, monitor and protect your system.
Loaded: loaded (/etc/systemd/system/elastic-agent.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2021-01-13 09:42:04 EST; 12min ago
Main PID: 786 (elastic-agent)
Tasks: 63 (limit: 4915)
CGroup: /system.slice/elastic-agent.service
├─ 786 elastic-agent
├─ 944 /opt/Elastic/Agent/data/elastic-agent-8a1a87/elastic-agent watch --path.config /opt/Elastic/Agent --path.home /opt/Elastic/Agent
├─1054 /opt/Elastic/Agent/data/elastic-agent-8a1a87/install/filebeat-7.11.0-SNAPSHOT-linux-x86_64/filebeat -E setup.ilm.enabled=false -E setup.template.enabled=false -E management.mode=x-pack-fleet -E management.enabled
├─1065 /opt/Elastic/Agent/data/elastic-agent-8a1a87/install/metricbeat-7.11.0-SNAPSHOT-linux-x86_64/metricbeat -E setup.ilm.enabled=false -E setup.template.enabled=false -E management.mode=x-pack-fleet -E management.ena
├─1076 /opt/Elastic/Agent/data/elastic-agent-8a1a87/install/filebeat-7.11.0-SNAPSHOT-linux-x86_64/filebeat -E setup.ilm.enabled=false -E setup.template.enabled=false -E management.mode=x-pack-fleet -E management.enabled
└─1085 /opt/Elastic/Agent/data/elastic-agent-8a1a87/install/metricbeat-7.11.0-SNAPSHOT-linux-x86_64/metricbeat -E setup.ilm.enabled=false -E setup.template.enabled=false -E management.mode=x-pack-fleet -E management.ena
lines 1-12/12 (END)

zeus@mainqa-atlcolo-10-0-6-185:~/elastic-agent-7.10.2-linux-x86_64$ ps ax | grep 944
944 ? Zs 0:00 [elastic-agent]

zeus@mainqa-atlcolo-10-0-6-185:~/elastic-agent-7.10.2-linux-x86_64$ systemd --version
systemd 232
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[ph]

This is interesting, @EricDavisX I don't think we have changed the unit name on debian in the current iteration, could that issues exist before but undetected?

[ph]

@blakerouse Anything we have don't recently that could have impact that?

[elasticmachine]

Pinging @elastic/agent (Team:Agent)

[michalpristas]

verified on systemd 232 and 229

[EricDavisX]

it indeed seems like it could have been there and was only unnoticed. i don't think it is urgent for 7.11 - it seems not to impact functionality and stops after 10 minutes of log build up. So, I'd say 7.12 or beyond

[blakerouse]

@ph nothing changed recently that makes this show up more

But I think on upgrade elastic-agent spawns a subprocess to watch the elastic-agent service, that runs for about 10 mins. So I would assume its related to that with upgrade. @michalpristas

[michalpristas]

yes this is when watcher tries to read PID by quering systemd by service name. what we see is error coming from systemd