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

Systemd provider is not correctly selected as the service provider if puppet is run as non root

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: PUP 6.9.0
    • Component/s: None
    • Template:
      PUP Bug Template
    • Team:
      Night's Watch
    • Story Points:
      1
    • Sprint:
      NW - 2019-09-18
    • Method Found:
      Needs Assessment
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      Hide
      PUP-7312 (released in 6.8.0) introduced a regression that prevented puppet's systemd provider from working when running as non-root. For example, the command "puppet resource service" did not include systemd services.
      Show
      PUP-7312 (released in 6.8.0) introduced a regression that prevented puppet's systemd provider from working when running as non-root. For example, the command "puppet resource service" did not include systemd services.
    • QA Risk Assessment:
      Needs Assessment

      Description

      Puppet Version: 6.8.1

      It seems that this change breaks a few things when Puppet is not being run as root, for example during spec tests (i.e. pdk test unit).

      At least under Ubuntu 16.04 and 18.04 the file /proc/1/exe is not accessible by regular users, so Puppet::FileSystem.exist?('/proc/1/exe') returns false and Puppet::FileSystem.readlink('/proc/1/exe').include?('systemd') fails with Errno::EACCES. ls also fails, obviously:

       
      $ ls /proc/1/exe
      ls: cannot read symbolic link '/proc/1/exe': Permission denied
      lrwxrwxrwx 1 root root 0 Sep  7 00:13 /proc/1/exe
      This has interesting implications in that now Puppet no longer recognizes that systemd is the correct service provider for recent Debian and Ubuntu releases. Thus spec tests for services fail with cryptic error messages like this:
      

      $ pdk test unit
      ...
      failed: rspec: ./spec/classes/service_spec.rb:9: Could not find the daemon directory (tested [/etc/sv,/var/lib/service])
      

        Attachments

          Issue Links

            Activity

              jsd-sla-details-panel

                People

                • Assignee:
                  jean Jean Bond
                  Reporter:
                  gheorghe.popescu Gheorghe Popescu
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  5 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: