Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-6222

puppet fails to manage multiple copies of an instantiated service under systemd

    Details

    • Type: Bug
    • Status: Accepted
    • Priority: Normal
    • Resolution: Unresolved
    • Affects Version/s: PUP 4.4.1
    • Fix Version/s: None
    • Component/s: None
    • Environment:

      RHEL 7 Linux with systemd

    • Template:
    • Team:
      Platform OS

      Description

      When using Puppet to manage multiple copies of an instantiated systemd service (eg: /usr/lib/systemd/system/mariadb@.service) Puppet does not handle the creation of symlinks under /etc/systemd/system/ correctly.

      The encountered case is if you have three Puppet services defined using the same systemd template (eg: mariadb@.service) with the Puppet service names of 'mariadb@120', 'mariadb@220', and 'mariadb@320' only one symlink will be created under /etc/systemd based on which stanza is first seen by the build process (eg: /etc/systemd/system/multi-user.target.wants/mariadb@120.service).

      Puppet will correctly manage the running states of all the configured services, but without the symlinks present when the system restarts the services without matching symlinks under /etc/systemd/system will not start as expected until the next Puppet run. Manually running systemctl enable/disable on the service names functions correctly so it appears to be caused by the way Puppet is handling identification of enabled systemd services.

        Attachments

          Activity

            jsd-sla-details-panel

              People

              • Assignee:
                Unassigned
                Reporter:
                michael.campfield Michael Campfield
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: