Ask Your Question
0

problem with bakuppc using puppet foreman

asked 2016-06-02 01:24:35 -0500

Arzyfex gravatar image

updated 2016-06-02 01:29:36 -0500

I have backuppc which is being handled by puppet and I am also using foreman. Below is my init.pp file :

class backuppc::service {
        if $::operatingsystemcodename == 'squeeze' {
                service { 'backuppc' : ensure => running, hasstatus => false, pattern => '/usr/share/backuppc/bin/BackupPC' }
        } else {
                service { 'backuppc' : ensure => running, hasstatus => true }
        }
        service { 'apache2' : ensure => running }
}

when I run puppet on node, it throws this reports on foreman :

class backuppc::service { if $::operatingsystemcodename == 'squeeze' { service { 'backuppc' : ensure => running, hasstatus => false, pattern => '/usr/share/backuppc/bin/BackupPC' } } else { service { 'backuppc' : ensure => running, hasstatus => true } } service { 'apache2' : ensure => running } }

change from stopped to running failed: Could not start Service[backuppc]: Execution of '/etc/init.d/backuppc start' returned 1: Starting backuppc...2016-05-31 17:13:25 Another BackupPC is running (pid 6731); quitting...

I am using backuppc of 3.1.0-9.1, which doesn't allow status in init script so using hasstatus => true is worthless. Any other help.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2016-06-02 16:54:37 -0500

DarylW gravatar image

You can read the documentation for a resource by typing puppet describe <resourcename> in your shell... part of the description for the service resource is here. Here is the relevant section describing your problem

Puppet 2.7 and newer expect init scripts to have a working status command.
If this isn't the case for any of your services' init scripts, you will
need to set `hasstatus` to false and possibly specify a custom status
command in the `status` attribute. As a last resort, Puppet will attempt to
search the process table by calling whatever command is listed in the `ps`
fact. The default search pattern is the name of the service, but you can
specify it with the `pattern` attribute.

You can create your own command (using pgrep, etc..) to verify status, and set hasstatus => false.

For completeness, I've attached the whole doc below.

ubuntu:~$ puppet describe service

service
=======
Manage running services.  Service support unfortunately varies
widely by platform --- some platforms have very little if any concept of a
running service, and some have a very codified and powerful concept.
Puppet's service support is usually capable of doing the right thing, but
the more information you can provide, the better behaviour you will get.
Puppet 2.7 and newer expect init scripts to have a working status command.
If this isn't the case for any of your services' init scripts, you will
need to set `hasstatus` to false and possibly specify a custom status
command in the `status` attribute. As a last resort, Puppet will attempt to
search the process table by calling whatever command is listed in the `ps`
fact. The default search pattern is the name of the service, but you can
specify it with the `pattern` attribute.
**Refresh:** `service` resources can respond to refresh events (via
`notify`, `subscribe`, or the `~>` arrow). If a `service` receives an
event from another resource, Puppet will restart the service it manages.
The actual command used to restart the service depends on the platform and
can be configured:
* If you set `hasrestart` to true, Puppet will use the init script's restart
command.
* You can provide an explicit command for restarting with the `restart`
attribute.
* If you do neither, the service's stop and start commands will be used.


Parameters
----------

- **binary**
    The path to the daemon.  This is only used for
    systems that do not support init scripts.  This binary will be
    used to start the service if no `start` parameter is
provided.

- **control**
    The control variable used to manage services (originally for HP-UX).
    Defaults to the upcased service name plus `START` replacing dots with
    underscores, for those providers that support the `controllable`
    feature.

- **enable**
    Whether a service should be enabled to start at boot.
    This property behaves quite differently depending on the platform;
    wherever possible, it relies on local tools to enable or disable
    a given service.
    Valid values are `true`, `false`, `manual`, `mask`.
    Requires features enableable.

- **ensure**
    Whether a service should be running.
    Valid values are ...
(more)
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2016-06-02 01:24:35 -0500

Seen: 35 times

Last updated: Jun 02 '16