I think that the issue is due to my puppet installation (from EPEL) not
configuring the init.d script properly. puppetmasterd doesn't think it is a
service.

Thanks for pointing me in the right direction.

On Mon, Oct 3, 2011 at 10:27 AM, Craig White <[email protected]> wrote:

>
> On Oct 3, 2011, at 6:50 AM, Sam wrote:
>
> > I have a puppetmaster module. In it is an 'ensure => running'
> > declaration. Runs of puppetd fail on this with the following error:
> >
> > err: /Stage[main]/Puppet::Master/Service[puppetmasterd]/ensure: change
> > from stopped to running failed: Could not start
> > Service[puppetmasterd]: Execution of '/sbin/service puppetmasterd
> > start' returned 1:  at /etc/puppet/modules/puppet/manifests/master.pp:
> > 15
> >
> > I assume that it is failing because puppetmasterd is already running
> > (hence the return code of '1'). But why does 'ensure => running' try
> > to restart the service, rather than just verify that it is running and
> > take action based on the response received?
> >
> > Here is the module:
> >
> >
> > class puppet::master {
> >        include puppet
> >        include puppet::params
> >
> > package { "puppet-server":
> >                ensure => installed,
> > }
> >
> > service { "puppetmasterd":
> >                ensure => running,
> >                hasstatus => true,
> >                hasrestart => false,
> >                enable => true,
> >                require => File["/etc/puppet/puppet.conf"]
> >        }
> > }
> >
> >
> > I changes hasrestart to false, thinking that is why i t was attempting
> > restart, but the error continues.
> >
> > I should also add that I'm a complete newb to puppet, so I'm sure I've
> > made a mistake.
> ----
> hasrestart should be set to true
>
> I have had a bit of a struggle myself with puppetmasterd but I never used
> puppet itself to maintain the status because if the master isn't running,
> nothing is going to be working anyway.
>
> Specifically, when you run into a problem with a service, you should try to
> execute from the command line, essentially duplicating the process that
> puppet would go through itself...
>
> [sudo] /sbin/service puppetmasterd status
> [sudo] /sbin/service puppetmasterd restart
>
> and see what comes from those commands. Of course the status of the
> puppetmasterd service is dependent upon the actual methods of installing and
> implementing them. When I was first starting out, I was running the
> puppetmasterd service and it was using webrick to offer the http/https
> connections to the clients. Once I switched to apache (actually now nginx)
> and passenger, then the puppetmasterd service had to be turned off because
> it was provided by the web server.
>
> Also, in my case, I installed puppet from gems and it seemed to want to
> locate the PID file in /var/run/puppet which didn't exist so I had to tailor
> the init.d script to do things like...
>
> if [ ! -d /var/run/puppet ]; then
>        mkdir -p /var/run/puppet
> fi
> chown puppet:puppet /var/run/puppet
>
> first, before actually starting up, but again, I am using Ubuntu and
> installed from the gem source so I would suspect that your mileage will
> indeed vary.
>
> Craig
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" 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-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" 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-users?hl=en.

Reply via email to