Uploaded image for project: 'Puppet Agent'
  1. Puppet Agent
  2. PA-1984

The Service Startup Type for the Puppet Enterprise for Windows Agent

    Details

    • Type: New Feature
    • Status: Accepted
    • Priority: Normal
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Template:
    • Team:
      Platform OS

      Description

      The service startup type of the Windows Puppet agent is set to Automatic, with no service dependencies. While it is an uncommon occurrence, it is possible for the Puppet Agent to start before the network components are available e.g. It would be possible for the Puppet Agent to start before the DHCP Client has finished configuring the network adapters. As I have only started using Puppet recently I have not seen this specific issue with Puppet "in the wild" but I have seen similar timing issues with other windows programs in the past, particularly with 802.1x authenticated networks.

      I see two ways that this issue could be avoided:

      1 . Change the Startup Type
      As of Server 2008 (I think?) and Vista an additional Startup type was added; Automatic (Delayed)

      From http://en.wikipedia.org/wiki/Windows_service
      Automatic: The service starts at system logon.
      Automatic (Delayed): The service starts a short while after the system has finished starting up. This option was introduced in Windows Vista in an attempt to reduce the boot-to-desktop time. However, not all services support delayed start

      It seems that "...a short while after..." is roughly 120 seconds after the last Automatic Service is started. This would ensure that the network and other services required by Puppet.

      2 . Specify the Service Dependencies for the Puppet Agent
      The Puppet Agent Service could specify which services it depends on e.g. Puppet would depend on the "Network Store Interface Service" for network interface information to be available.

      The service dependencies method seems a little harder to manage because PuppetLabs does not know what technologies module authors will use. As an example, say I created a puppet class that runs a PowerShell Script that uses information from the Tivoli Backup Service. In that case the Puppet Agent now depends on the Tivoli Backup Service to be running for a successful catalog run. There is no way that PuppetLabs would know about this dependency and put it in their installation script.

      Out of both options, Option 1 seems to make the most sense and is pretty easy to implement.

        Attachments

          Issue Links

            Activity

              jsd-sla-details-panel

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  redmine.exporter redmine.exporter
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:

                    Zendesk Support