Bug #10980

Service provider in RedHat will not create K?? stop scripts

Added by Andoni Auzmendi over 1 year ago. Updated 4 months ago.

Status:AcceptedStart date:11/21/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:service
Target version:-
Affected Puppet version:2.7.6 Branch:
Keywords:service redhat linux enable

Description

When a service is set to be enabled the provider/service/redhat.rb provider will run “/sbin/chkconfig $name on” which will only create the links for starting the service but will not for stopping it. The correct command is “/sbin/chkconfig —add $name”.

This is important for those services that require stopping cleanly before other services.

puppet-10980.patch Magnifier (636 Bytes) Greg Poirier, 02/18/2013 11:03 am

History

#1 Updated by Michael Stahnke over 1 year ago

  • Status changed from Unreviewed to Accepted
  • Target version set to 2.7.x

Confirmed.

[root@centos5-64 init.d]# chkconfig --del httpd
[root@centos5-64 init.d]# find /etc/rc.d/ | grep httpd
/etc/rc.d/init.d/httpd
[root@centos5-64 init.d]# cat test.pp 
service { "httpd":
enable => true
}
[root@centos5-64 init.d]# puppet apply --verbose test.pp 
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:48: warning: parenthesize argument(s) for future version
info: Applying configuration version '1321582482'
notice: /Stage[main]//Service[httpd]/enable: enable changed 'false' to 'true'
notice: Finished catalog run in 0.14 seconds
[root@centos5-64 init.d]# find /etc/rc.d/ | grep httpd
/etc/rc.d/rc5.d/S85httpd
/etc/rc.d/rc2.d/S85httpd
/etc/rc.d/rc3.d/S85httpd
/etc/rc.d/init.d/httpd
/etc/rc.d/rc4.d/S85httpd
[root@centos5-64 init.d]#

We should be running chkconfig —add $service then chkconfig on $service

#2 Updated by Stijn Hoop over 1 year ago

Please look into removing /etc/rc.d/rc?.d/K*service as well when a service is disabled.

#3 Updated by Jason Koppe about 1 year ago

Is there any progress on this? Even if we fix the provider to do chkconfig service —add, how do we want to handle fixing all of the services which were installed with the current provider which does chkconfig service on?

#4 Updated by Andrew Parker 6 months ago

  • Target version deleted (2.7.x)

#5 Updated by Greg Poirier 4 months ago

This is effecting a couple of the packages we deploy. We’re on the 2.7.x branch. I wouldn’t mind fixing the bug, but I’m not entirely sure where to start. I was looking at provider/service/redhat.rb, but stopped at line 9: commands :chkconfig => “/sbin/chkconfig”.

As of RHEL 6.3, chkconfig still isn’t creating the appropriate K scripts for init scripts of the format “# chkconfig: ”, but running chkconfig —levels 016 off does create K scripts. We are going about this with a defined type at the moment. Since RedHat will probably never, ever change chkconfig — would it behoove puppet to adapt?

Would something like the attached patch be okay? I haven’t tested it or anything, but I wanted to make sure that the basic principle is okay. If redhat, also manually turn the service off at run-levels 016.

#6 Updated by Jos van der Meer 4 months ago

Hi Greg. The correct way to add a service in the runlevels specified in the init script is : “chkconfig —add servicename”. That way a Start script will be run in the appropriate runlevels (e.g. 3 4 5) and a Kill script for the other runlevels.

def enable
output = chkconfig("--add", @resource[:name])

To remove a service:

def disable
output = chkconfig("--del", @resource[:name])

#7 Updated by Greg Poirier 4 months ago

Hey Jos.

Unfortunately, on RHEL 6.3 (and at least as far back as 6.2), we aren’t seeing K scripts created at all by chkconfig (from outside puppet or by service objects). E.g., the following only creats start scripts:

chkconfig jetty on

Where /etc/init.d/jetty has the following

# chkconfig: 2345 84 16

Only produces /etc/rc[2345].d/S84jetty

but no /etc/rc[016].d/K16jetty

Now, I understand that this is, perhaps, a bug with chkconfig, but when’s the last time you tried filing a bug with Redhat? :–/

#8 Updated by R.I. Pienaar 4 months ago

@greg – did you chkconfig —add first before doing on/off?

#9 Updated by Greg Poirier 4 months ago

Oh, I see what —add does now.

No, we haven’t been doing that manually. We install jetty via puppet from a tgz distribution, and not a package. Might that matter? We aren’t running chkconfig —add manually from within our jetty module. We install via tar, and then do a service { ‘jetty’: } stanza (approprately filled, not just empty).

#10 Updated by R.I. Pienaar 4 months ago

Packages tend to do the —add in the post install scripts. You’re basically just not installing the software properly

#11 Updated by Greg Poirier 4 months ago

That’s pretty obvious now. :)

Thanks for the schooling. I’ll fix this on our end.

#12 Updated by Jason Koppe 4 months ago

R.I. Pienaar wrote:

Packages tend to do the —add in the post install scripts. You’re basically just not installing the software properly

This seems like a weak argument for not fixing this in Puppet. Over time, with Puppet & Chef, I expect (hope) that scripts in packages (RPMs, DEBs) will begin to become less complex as our modules and recipes will contain more logic.

Additionally, what about systems which instantiate multiple services from one package? For example, I install elasticsearch (and mongodb, and redis, and apache httpd) and run two separate instances of the elasticsearch per node. Such service instances would not be able to rely on the package’s chkconfig —add. In the case of mongodb or redis or any datastore, this could lead to some data issues when we do shutdown -r now and SysV init doesn’t stop the process like it should.

Also available in: Atom PDF