What would you like to be added:
During nodeadm init it assumes that if you're running Ubuntu OS then you are managing the SSM daemon via snapd. This assumption is hard coded here.
Either the logic should be more robust to find/discover the systemd unit name through a list and filter/find approach or the user should be able to influence this logic at nodeadmin init runtime.
Why is this needed:
We aim for deterministic machine images and as a result, prefer to install all system dependencies during image build time rather than at runtime. The AWS SSM agent is installed on our Ubuntu images using dpkg/deb files and not snapd. The nodeadm install step handles this gracefully by skipping the installation of the SSM agent if it already exists on the system.
However, during runtime when the machine bootstrap runs nodeadm init, it assumes the SSM agent is installed via snapd and fails:
{"level":"info","ts":"2025-12-30T23:26:47.210Z","caller":"node/node.go:23","msg":"Setting up hybrid node provider..."}
{"level":"info","ts":"2025-12-30T23:26:47.213Z","caller":"hybrid/validator.go:91","msg":"Validating configuration..."}
{"level":"info","ts":"2025-12-30T23:26:47.213Z","caller":"flows/init.go:33","msg":"Configuring Aws..."}
{"level":"info","ts":"2025-12-30T23:26:47.213Z","caller":"ssm/config.go:44","msg":"Registering machine with SSM agent"}
{"level":"info","ts":"2025-12-30T23:26:47.691Z","caller":"ssm/config.go:66","msg":"Machine registered with SSM, assigning instance ID as node name","instanceID":"mi-XXXXXXXXXXXXXXX"}
{"level":"fatal","ts":"2025-12-30T23:26:47.693Z","caller":"nodeadm/main.go:57","msg":"Command failed","error":"configuring aws credentials with SSM: Unit file snap.amazon-ssm-agent.amazon-ssm-agent.service does not exist."}
The amazon-ssm-agent is however installed on the machine:
$ which amazon-ssm-agent
/usr/bin/amazon-ssm-agent
$ systemctl status amazon-ssm-agent.service
● amazon-ssm-agent.service - amazon-ssm-agent
Loaded: loaded (/lib/systemd/system/amazon-ssm-agent.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2025-12-30 23:27:59 UTC; 1h 17min ago
Main PID: 10582 (amazon-ssm-agen)
Tasks: 50 (limit: 629145)
Memory: 57.7M
CPU: 5.873s
CGroup: /system.slice/amazon-ssm-agent.service
├─10582 /usr/bin/amazon-ssm-agent
└─10604 /usr/bin/ssm-agent-worker
What would you like to be added:
During
nodeadm initit assumes that if you're running Ubuntu OS then you are managing the SSM daemon viasnapd. This assumption is hard coded here.Either the logic should be more robust to find/discover the systemd unit name through a list and filter/find approach or the user should be able to influence this logic at
nodeadmin initruntime.Why is this needed:
We aim for deterministic machine images and as a result, prefer to install all system dependencies during image build time rather than at runtime. The AWS SSM agent is installed on our Ubuntu images using dpkg/deb files and not
snapd. Thenodeadm installstep handles this gracefully by skipping the installation of the SSM agent if it already exists on the system.However, during runtime when the machine bootstrap runs
nodeadm init, it assumes the SSM agent is installed viasnapdand fails:The
amazon-ssm-agentis however installed on the machine: