Issue #16125 has been updated by Josh Cooper.
Just to be clear, puppet currently has two agent pid-like files. In 2.7.x, there's <pre> lockfile: /var/lib/puppet/state/puppetdlock pidfile: /var/run/puppet/agent.pid </pre> The lockfile (poorly) protects against concurrent puppet runs. For example, the check for whether we are disabled? or running? doesn't occur while holding the lock, so it's possible for multiple agents to race, but whatever, that's a separate issue. >From what I understand, mcollective uses the pidfile to differentiate between >running, idle, and stopped. But since puppet on windows doesn't create a >pidfile, mcollective always thinks puppet is stopped (or disabled if the >lockfile has zero-length). I think the question about whether to write a pidfile depends on how similar puppet should behave on Windows as compared to other platforms. We could create a pidfile. But mcollective can't send USR1 on Windows, so how to signal? I've looked into two alternative solutions. One is to use the paramchange service notification (which is the most direct analog to USR1). However, there is a bug in the win32-service gem (which I have a patch for) whereby ruby services never get notified. The nice thing about this solution is that we get notified asynchronously of the notification, so we can easily wake up the ruby main thread which is doing `sleep(runinterval)`. The other option is to create a named event, e.g. "PuppetStartEvent". This is pretty standard windows practice as a way to signal background processes. The existence or absence of the event would serve as the "pidfile". The event is removed from global namespace when the owning process terminates. The downside of this solution is that waiting on the event in ruby is a pain. We have to poll every X seconds until runinterval seconds has elapsed. We already do this when launching external processes, but the polling is limited to the lifetime of the child process. But to wait on an event, we'd be polling all the time, causing CPU spikes. However, Andy pointed out that mcollective and the puppet service on Windows both just run `puppet agent --onetime`. The main benefit to having mcollective signal the puppet service is that mcollective doesn't need to know where puppet is installed. Also, mcollective and puppet will both be running as LocalSystem, so there shouldn't be any "it depends who mcollective is running as" issues. At this point, I'm leaning towards not creating a pidfile, but have mcollective (really the puppetd agent plugin) query the service control manager, something like: <pre> return 'disabled' if disabled return 'running' if locked && service.running? return 'idle' if ! locked && service.running? return 'stopped' if ! service.running? </pre> In the case, of idle, I think mcollective should just execute `puppet agent --onetime` like it does in `runonce_background`. Thoughts? ---------------------------------------- Bug #16125: Puppet running as windows service does not create pidfile https://projects.puppetlabs.com/issues/16125#change-71259 Author: Josh Cooper Status: Needs More Information Priority: Normal Assignee: Category: Target version: 3.0.0 Affected Puppet version: Keywords: windows service pidfile Branch: Puppet does not create a pidfile when running as a windows service. On Unix, this happens in the `daemon.rb` code, but since we never daemonize on Windows, this doesn't happen. Instead the daemon service wrapper needs to create this so that mcollective can detect that the service is running and signal it to run. -- 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 post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
