Package Test: Systemctl being degraded

[MovieStoreGuy]

Context

When trying to perform the releases for v0.141.0, there was an issue trying to run:

• deb package
• rpm package

The reported error was:

Failed to connect to system scope bus via local transport: No such file or directory

For the time being, I had removed the assert method to validate the expected systemd component is running.

What next?

• Understand if this assert method is required?
  • Or should be changed to a different means
• Decided to remove or fix assert.

[dosubot]

Hi @MovieStoreGuy! I'm Dosu and I’m helping the opentelemetry-collector-releases team.

The systemd validation in package tests currently relies on running systemctl commands inside a container, which can fail if systemd or D-Bus isn't available or properly configured in the CI environment. This is a common issue in containerized or minimal test runners, as seen in previous failures and discussions about systemd not running as PID 1 or the system bus being inaccessible source.

To avoid brittle tests and CI failures, consider making systemd checks conditional: only run systemctl-based assertions if systemd is detected and functional (for example, check if systemd is PID 1 before running systemctl). This approach was previously proposed and implemented for package scripts to improve robustness source. For RPM scripts, appending || : to systemctl commands is a common pattern to prevent failures when systemctl is unavailable.

If you remove the assert entirely, you risk missing regressions in service installation and lifecycle, but if you keep it unconditional, you may block releases due to environment limitations. The best practice is to keep the validation but make it environment-aware, skipping or soft-failing the check when systemd/D-Bus is not available, and possibly supplementing with log or file checks for service installation.

You can implement this by updating your test scripts to check for systemd before running systemctl commands, and by handling failures gracefully rather than aborting the test run source. This will maintain coverage without causing unnecessary CI failures.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}