rpm package should not start or enable the service upon installation

[sproberts92]

The rpm package should not start or enable the service upon installation. There are a situations in which this will break, one of which I hit today, and it's generally unexpected for system administrators of rpm based distros.

In my specific example:

• Another service is usually configured to listen on one of the ports that otelcol-contrib listens on in the default config
• The host was rebuilt
• otelcol was re-installed, stealing the port from the other service
• Templating my otelcol config failed for unrelated reasons and thus that port was not freed up before the other service was started
• The other service failed to start

It's also against rpm packaging guidelines on scriptlets and default services, as the default configuration listens on several ports on 0.0.0.0.

(I note also that there are rpm features to handle the things these scripts do, but moving away from nFPM is a whole other kettle of fish, so I won't dwell on that here).

I don't use any deb based distros, but I think starting packages is on install is more common there? Perhaps we need separate postinstall scripts for deb vs rpm? I am not familiar with nFPM but it does appear to support this from a quick read of the docs.

If you agree that this behaviour should change, I am willing to put up a PR.

[dosubot]

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

You're right—currently, the RPM package for OpenTelemetry Collector does start and enable the systemd service automatically on installation, which is against Fedora packaging guidelines and can cause issues like port conflicts and log flooding, especially with the default config listening on multiple ports example.

This behavior comes from the shared postinstall.sh script used for both RPM and DEB packages in the nFPM configuration. The script runs systemctl enable and systemctl restart if systemd is present and a config file exists example.

nFPM supports per-format overrides, so you can have separate post-install scripts for RPM and DEB. To fix this, you could update the .goreleaser.yaml (or equivalent nFPM config) to use a no-op or minimal post-install script for RPM, while keeping the current behavior for DEB if desired. For example:

nfpms:
  - package_name: otelcol
    scripts:
      postinstall: postinstall.sh
    overrides:
      rpm:
        scripts:
          postinstall: postinstall-rpm.sh  # This script would NOT start/enable the service
      deb:
        scripts:
          postinstall: postinstall.sh      # This script CAN start/enable the service

And postinstall-rpm.sh could simply reload systemd (if needed) but not enable or start the service.

There is support from maintainers for aligning RPM behavior with Fedora guidelines discussion, so a PR making this change would be well-founded. If you want to proceed, updating the nFPM config and scripts as above should resolve the issue.

To reply, just mention @dosu.

---

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