Issue #2773 has been updated by Nigel Kersten.
(sent via email to Eric while projects.reductivelabs was down) > There were a couple of things that struck me about your plist. > > a) you're replacing a system plist, this is a bad idea due to OS > updates potentially stomping over it. Better to leave the system one > disabled and make a new one. > b) you should use your own reverse domain notation for the label so > it's a separate job to the system one. > c) It should go into /Library/LaunchDaemons, not /System/Library/LaunchDaemons > > Even so... I can't seem to replicate this, although I messed up while > testing and deleted the original postfix plist, so I need to go do > some digging to retrieve it. > > Did you possibly have the system version already running and then > dropped your plist on top of it? That's about the only scenario I can > think of that might produce this behaviour that I haven't tested. > > The provider should cope with the actual job plist changing, but I can > see there might be problems with certain kinds of changes... > Eric is hoping to get to this next week, and this weekend I'll run through some more tests with the various scenarios. ---------------------------------------- Bug #2773: buglet in provider/service/launchd.rb http://projects.reductivelabs.com/issues/2773 Author: eric sorenson Status: Accepted Priority: Normal Assigned to: Nigel Kersten Category: service Target version: 0.25.2 Affected version: 0.25.1 Keywords: osx launchd Branch: I added a persistent postfix plist to replace the run-on-demand one distributed with OSX. (Which causes our nagios mailqueue check to fail annoyingly because qmgr doesn't run all the time). So upon copying the plist, process status should have been 'enabled' but 'stopped'. But it wouldn't start up by itself: <pre> debug: Service[postfix](provider=launchd): Executing 'launchctl load /System/Library/LaunchDaemons/org.postfix.master.plist' err: //mail::nullclient/Service[postfix]/ensure: change from stopped to running failed: Unable to start service: org.postfix.master at path: /System/Library/LaunchDaemons/org.postfix.master.plist </pre> I manually got it working with 'launchctl load -w' , but the conditional in the start() method was not being triggered. After resetting my system back to previous state and changing the check as below, I get the expected result: <pre> debug: //mail::nullclient/Service[postfix]: Changing ensure debug: //mail::nullclient/Service[postfix]: 1 change(s) debug: Service[postfix](provider=launchd): Executing 'launchctl load -w /System/Library/LaunchDaemons/org.postfix.master.plist' notice: //mail::nullclient/Service[postfix]/ensure: ensure changed 'stopped' to 'running' </pre> So it seems 'enabled' (in puppet's view of things) but 'stopped' may still need -w to overcome a 'disabled' key in launchd's little mind. What do you think? <pre> --- a/lib/puppet/provider/service/launchd.rb +++ b/lib/puppet/provider/service/launchd.rb @@ -163,7 +163,7 @@ Puppet::Type.type(:service).provide :launchd, :parent => :base do did_enable_job = false cmds = [] cmds << :launchctl << :load - if self.enabled? == :false # launchctl won't load disabled jobs + if self.enabled? == :false || self.status == :stopped # launchctl won't load disabled jobs cmds << "-w" did_enable_job = true end </pre> -- 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://reductivelabs.com/redmine/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.
