[Bug]: Successful auto-update exits with status 1 due to installer_tmp: unbound variable

[Fabrizioso]

Describe the bug

A successful Pulse auto-update is reported by systemd as failed because pulse-auto-update.sh terminates with:
installer_tmp: unbound variable
The actual installation succeeds, the new version is verified, and Pulse is running normally on the new version. However, after logging Auto-update check completed, the updater exits with status 1.

This causes pulse-update.service to enter the failed state even though the update itself was successful.

I observed this both during an earlier update to v6.3.2 and again when updating from v6.3.2 to v6.4.1.

To reproduce

1. Run a systemd-based Pulse installation with automatic updates enabled.
2. Start from Pulse v6.3.2.
3. Allow or manually trigger the update to v6.4.1:
   systemctl start pulse-update.service
4. Allow the installation to complete successfully.
5. Check:
   systemctl status pulse-update.service
6. The update has completed and the installed version is v6.4.1, but pulse-update.service is in the failed state with:
   installer_tmp: unbound variable
   Verification after the update:
   /opt/pulse/bin/pulse --version
   returns:
   Pulse v6.4.1
   and
   systemctl status pulse
   shows Pulse as active and running.

Expected behavior

If the installer completes successfully and the installed version is successfully verified, pulse-update.service should exit with status 0.

A cleanup trap should not cause an otherwise successful update to be reported as failed.

Additional actionable topics

none

Pulse version

v6.3.2

Agent version

none

Image tag or digest

No response

Installation type

Docker

Relevant logs or diagnostics

The issue appears related to the RETURN trap installed inside perform_update().

Relevant code in pulse-auto-update.sh v6.4.1:
perform_update() {
    local new_version=$1
    local service_name=$(detect_service_name)
    local installer_tmp=""
    local signature_tmp=""

    ...

    trap 'ensure_service_restarted "$service_name" "$service_was_active"' RETURN

    ...

    installer_tmp=$(mktemp /tmp/pulse-update-installer.XXXXXX)
    signature_tmp=$(mktemp /tmp/pulse-update-installer.sig.XXXXXX)

    trap 'rm -f "$installer_tmp" "$signature_tmp"; ensure_service_restarted "$service_name" "$service_was_active"' RETURN

installer_tmp and signature_tmp are local to perform_update().

It appears possible that the RETURN trap remains installed after perform_update() returns and is subsequently invoked when another function returns. At that point the local variables no longer exist. With nounset enabled, expanding $installer_tmp then results in the observed error.

The update itself completes successfully:

installer: [SUCCESS] Pulse installation completed!

Update successfully installed
Version verified: v6.4.1
Update completed successfully to v6.4.1
Auto-update check completed

Immediately afterwards:
/usr/local/bin/pulse-auto-update.sh: line 564: installer_tmp: unbound variable

pulse-update.service: Main process exited, code=exited, status=1/FAILURE
pulse-update.service: Failed with result 'exit-code'.
Failed to start pulse-update.service - Automatic Pulse update check and install.

Confirmations

• I verified the exact Pulse version and image reference from the running instance.
• I searched existing issues for duplicates.

[pulse-triage]

Confirmed. The update itself completes; the non-zero exit comes from a cleanup trap left installed after perform_update returns, which then re-runs against out-of-scope locals under set -u.

Run systemctl reset-failed pulse-update.service to clear the failed state; the installed v6.4.1 is unaffected.

How Pulse handles triage

[pulse-triage]

v6.4.5-rc.1 is published with the cleanup-trap fix. Update with sudo /bin/update --version v6.4.5-rc.1 and confirm a successful update now exits cleanly instead of leaving pulse-update.service failed. Post the result here.

How Pulse handles triage