Startup fails on first attempt after service update — `aos-unit-dnsmasq.service` already exists

[vladyslavabohdanova]

After updating aos-unit to a newer version, the service fails on its first startup attempt because the transient systemd unit aos-unit-dnsmasq.service from the previous run was not fully torn down before the new version tries to create it.

The service recovers automatically on the second attempt (after the systemd restart delay), so it is not a blocking issue — but it introduces an unnecessary ~10 second delay and a logged failure on every update/restart cycle.

Steps to Reproduce

1. Have aos-unit 1.1.1~jammy running with an existing aos-unit-dnsmasq.service transient unit active
2. Update aos-unit to a newer version 1.1.2~jammy (service is stopped and restarted as part of the update)
3. Observe the first startup attempt fails

Expected Behavior

The startup script should detect and stop any existing aos-unit-dnsmasq.service transient unit before attempting to create a new one, ensuring a clean first-attempt startup after an update.

Actual Behavior

The startup script attempts to create aos-unit-dnsmasq.service while a stale unit from the previous session still exists, causing an immediate failure:

aos-unit:startup: Starting dnsmasq as transient unit: aos-unit-dnsmasq.service
Failed to start transient service unit: Unit aos-unit-dnsmasq.service already exists.
aos-unit:startup: Startup failed (exit 1). Rolling back...
aos-unit:startup: Rollback complete.
systemd[1]: aos-unit.service: Control process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start AosEdge Unit VM Manager.

Systemd then schedules a restart, and the second attempt succeeds normally.

Logs

Full log snippet (first failed attempt + successful retry)

Mar 05 09:38:49 systemd[1]: Stopping AosEdge Unit VM Manager...
Mar 05 09:38:49 aos-unit[7514]: aos-unit:network-helper: Removing NAT rules
Mar 05 09:38:49 aos-unit[7522]: aos-unit:cleanup: nft table inet aos_unit removed
Mar 05 09:38:49 aos-unit[7522]: aos-unit:cleanup: Removing bridge: aosbrec28bf
Mar 05 09:38:49 aos-unit[7522]: aos-unit:cleanup: Cleanup complete
Mar 05 09:38:49 systemd[1]: Stopped AosEdge Unit VM Manager.
Mar 05 09:38:49 systemd[1]: Starting AosEdge Unit VM Manager...
Mar 05 09:38:49 aos-unit[7537]: aos-unit:startup: Creating bridge: aosbrec28bf (10.0.0.1)
Mar 05 09:38:49 aos-unit[7537]: aos-unit:startup: Starting dnsmasq as transient unit: aos-unit-dnsmasq.service
Mar 05 09:38:49 aos-unit[7575]: Failed to start transient service unit: Unit aos-unit-dnsmasq.service already exists.
Mar 05 09:38:49 aos-unit[7537]: aos-unit:startup: Startup failed (exit 1). Rolling back...
Mar 05 09:38:49 systemd[1]: aos-unit.service: Failed with result 'exit-code'.
Mar 05 09:38:49 systemd[1]: Failed to start AosEdge Unit VM Manager.
Mar 05 09:38:59 systemd[1]: aos-unit.service: Scheduled restart job, restart counter is at 1.
Mar 05 09:38:59 systemd[1]: Starting AosEdge Unit VM Manager...
Mar 05 09:38:59 aos-unit[7687]: aos-unit:startup: dnsmasq started (systemd unit aos-unit-dnsmasq.service)
Mar 05 09:38:59 aos-unit[7687]: aos-unit:startup: Startup complete
Mar 05 09:39:00 systemd[1]: Started AosEdge Unit VM Manager.

Environment

• Host: AWS EC2
• Host architecture: x86_64
• Triggered by: Service update (version upgrade)

[klogg]

I assume this happened only one time on the upgrade to the new version and does not repeat anymore?

I confirm this happens on every restart; this is a defect indeed.
I will provide a W/A release soon, but a proper solution must be developed that uses the restarted systemd units in an order that observes configuration updates between the restarts.

[klogg]

@vladyslavabohdanova please mark the issue as defect, thanks!

[vladyslavabohdanova]

I assume this happened only one time on the upgrade to the new version and does not repeat anymore?

Yes, this occurred only once during the upgrade to the new version and has not happened again since.

[vladyslavabohdanova]

@vladyslavabohdanova please mark the issue as defect, thanks!

I’m currently unable to add assignees, labels, type, projects, milestones, or relationships to issues.
Could you please review my permissions or adjust the repository settings so I can manage these issue attributes?

[klogg]

I assume this happened only one time on the upgrade to the new version and does not repeat anymore?

Yes, this occurred only once during the upgrade to the new version and has not happened again since.

bugfix to be released in v1.1.3 and full implementation will be done in #11

[klogg]

@vladyslavabohdanova please mark the issue as defect, thanks!

I’m currently unable to add assignees, labels, type, projects, milestones, or relationships to issues. Could you please review my permissions or adjust the repository settings so I can manage these issue attributes?

Added the whole team for reports