service can't be run on CentOS

[viktortnk]

Error: Could not start Service[mesos-slave]: Execution of '/sbin/service mesos-slave start' returned 1: mesos-slave: unrecognized service
Wrapped exception:

Execution of '/sbin/service mesos-slave start' returned 1: mesos-slave: unrecognized service
Error: /Stage[main]/Mesos::Slave/Mesos::Service[slave]/Service[mesos-slave]/ensure: change from stopped to running failed: Could not start Service[mesos-slave]: Execution of '/sbin/service mesos-slave start' returned 1: mesos-slave: unrecognized service

specifying provider => 'upstart' solves the issue

service { "mesos-${name}":
    ensure     => 'running',
    provider   => 'upstart',
    hasstatus  => true,
    hasrestart => true,
    enable     => $enable,
    subscribe  => [ File['/etc/default/mesos'],
      File["/etc/default/mesos-${name}"]
    ],
  }

[deric]

Which version of CentOS and Puppet do you have? Is it 6? Have a look here: #8

We can't simply use upstart provider for whole RedHat family. It gets more complicated, RHEL7 uses systemd. Managing services should be generally handled by Puppet, there is a bug related to this issue:
https://tickets.puppetlabs.com/browse/PUP-876
which should be fixed in Puppet 3.5.0

Rather than copying this logic from Puppet we've decided to keep the code as simple as possible, which should ensure compatibility with future releases of RedHat OS.

[viktortnk]

Ok. Sorry, makes sense.

It is CentOS 6.5 and Puppet 3.6.2

[deric]

If you would insist on this we can add some parameter like force_provider to override Puppet configuration. Or is it possible to solve this by upgrading Puppet?

[viktortnk]

Puppet 3.6.2 is fairly latest production version. And it doesn't work with it.

I would happy if we can introduce change to specify provider (force_provider).

[deric]

Ok, sure if there's no other workaround we could add it. @wleese what do you think?

[wleese]

Strange. Has the service script properly been installed into init.d? More details would be great. It looks like init.d isnt used, so if that isnt happening, it d be good to know what puppet is doing.

[viktortnk]

@wleese No, the script is placed into /etc/init/ directory, which is used by upstart

[wleese]

Ah! Of course. The real issue here is the rpm. It only has an upstart script and doesnt present anything useful for non upstart systems.
So the bug is with the rpm, not the puppet module. The override_provider param should provide a workaround until mesos finally starts including the sysvinit script like all redhat rpms.
Another alternative would be to have this module setup its own sysvinit, but that ll break once/if the rpm changes.

[deric]

Ok, if I understand it correctly we could fix this by changing mesos packaging: https://github.com/mesosphere/mesos-deb-packaging/blob/master/build_mesos#L204

    redhat/6|redhat/6.*|centos/6|centos/6.*)
      mkdir -p etc/init
      cp "$this"/ubuntu/master.upstart etc/init/mesos-master.conf
      cp "$this"/ubuntu/slave.upstart etc/init/mesos-slave.conf ;;

RedHat 6 is by default looking into /etc/init.d? And supports both init.d and upstart scripts? (I'm sorry I have zero experience with RedHat Linux).

[wleese]

Well, the github title says it deals with debian packaging, not redhat..
really weird. My guess is that they were lazy and changed their deb
packaging scripts to have hacky redhat support.

RedHat supports both upstart and sysvinit (init.d), but really only uses
init.d. So Puppet will only try to use sysvinit on redhat systems (unless
we provide the override_provider param).

Structural fix would require writing and testing a proper sysvinit script (
http://www.thegeekstuff.com/2012/03/lsbinit-script/) and then getting mesos
to use it. (pull request and a change to the lines you mentioned in your
comment to reference the sysvinit script, not the upstart cfg file).

Frankly, providing the override provider parameter is the best short term
solution.

On Mon, Sep 1, 2014 at 10:12 PM, deric notifications@github.com wrote:

Ok, if I understand it correctly we could fix this by changing mesos
packaging:
https://github.com/mesosphere/mesos-deb-packaging/blob/master/build_mesos#L204

redhat/6|redhat/6.*|centos/6|centos/6.*)
  mkdir -p etc/init
  cp "$this"/ubuntu/master.upstart etc/init/mesos-master.conf
  cp "$this"/ubuntu/slave.upstart etc/init/mesos-slave.conf ;;

RedHat 6 is by default looking into /etc/init.d? And supports both init.d
and upstart scripts? (I'm sorry I have zero experience with RedHat Linux).

—
Reply to this email directly or view it on GitHub
#16 (comment).

[deric]

That repo is a fork of mine repository which was intended as Debian packing. Partially mine fault :)

I'll submit an issue to mesosphere repo, until then, you can use force_provider. For Fedora (it might work also on CentOS 7) there seems to be native packages: http://koji.fedoraproject.org/koji/packageinfo?packageID=17691 (hopefully better ones).

[tomstockton]

It looks like there isn't an updated tag for this repo which includes the force_provider workaround.

Therefore I can't use this module from Puppetforge at the moment.

Any chance of creating an updated tag?

[deric]

Sure, I've tagged it as v0.5.0 and it's available at Puppetforge.