Issue #22839 has been updated by Glenn Sarti.
Typo: 1. Specify the Service Dependencies.... Should read; 2. Specify the Service Dependencies.... ---------------------------------------- Feature #22839: The Service Startup Type for the Puppet Enterprise for Windows Agent https://projects.puppetlabs.com/issues/22839#change-98725 * Author: Glenn Sarti * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: windows service agent * Branch: ---------------------------------------- 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
