service_status being set without honoring custom service_name

[Christian Ruppert]

Describe the Bug

Hi,

we're using 8.2.1 right now. We have a custom service_name being set, in our case it's "postgresql-11".
That is fine so far (it seems) except for service_status.
manifests/params.pp doesn't honor a custom service_name so it's defining "postgresql" as default which is then used by service_status.

This results in having a service definition in
manifests/server/service.pp for "postgresql-11" (the custom one) but having a service status defined as e.g. "systemctl status postgresql". This then results into the service being treated as stopped / not running and Puppet trying to start postgresql-11 then (which is already running) on every Puppet run.

Expected Behavior

service_status or params.pp should honor custom settings

Steps to Reproduce

Broken e.g.:

  class { 'postgresql::server':
    package_name         => 'postgresql11-server',
    service_name         => 'postgresql-11',
    ...
  }

Working:

  class { 'postgresql::server':
    package_name         => 'postgresql11-server',
    service_name         => 'postgresql-11',
    service_status       => 'systemctl status postgresql-11', # puppetlabs-postgresql defaultet zu "postgresql"
    ...
  }

Environment

• CentOS 7.9.2009
• Puppet 7.21.0
• puppetlabs-postgresql 8.2.1

[Tim Mooney]

We're using puppetlabs-postgresql 9.2.0 and this issue is still present. It impacts the default OS package service name on RHEL 7, RHEL 8, and RHEL 9.