Feature #7999

Add a service provider that manages systemd services

Added by Jeff Ollie 11 months ago. Updated 28 days ago.

Status:Closed Start date:09/09/2011
Priority:Normal Due date:
Assignee:Nigel Kersten % Done:

0%
Category:service
Target version:2.7.4
Affected Puppet version: Branch:https://github.com/jcollie/puppet/tree/feature%2Fmaster%2F7999-systemd-services
Keywords:
Votes: 5

Description

systemd is the default system/service manager in Fedora 15 and will likely become the default on other Linux distributions in the future. While systemd provides a compatibility layer that allows the standard “redhat” Puppet service provider to manage some services on a systemd system, as more services are converted to native systemd services the compatibility layer will become less and less useful. For more information on systemd see:

http://www.freedesktop.org/wiki/Software/systemd

Subtasks

Bug #9414: #7999 Needs more test coverageAccepted

History

#1
Updated by Jeff Ollie 11 months ago

Patches here:

https://github.com/jcollie/puppet/tree/feature%2Fmaster%2F7999-systemd-services

#2
Updated by Adrien Thebo 11 months ago

  • Status changed from Unreviewed to Requires CLA to be signed

Thank you very much for the patch! Could you sign the Contributor License Agreement? Also, could you sent the patches to the puppet-dev mailing list for review? Instructions for doing so should be available at http://projects.puppetlabs.com/projects/puppet/wiki/Development_Development_Lifecycle .

#3
Updated by Jeff Ollie 11 months ago

I’ve now signed the CLA

#4
Updated by Ben Hughes 11 months ago

  • Status changed from Requires CLA to be signed to Accepted

Wonderful. Thank you (and thank for you writing tests!)

#5
Updated by Robin Powell 9 months ago

Is there any version (dev or otherwise) of puppet that has these changes rolled in? Puppet is not reliably managing my Fedora 15 systems because of this (for example, ntpd was not set to start on boot!).

-Robin

#6
Updated by James Turnbull 9 months ago

  • Category set to service
  • Status changed from Accepted to In Topic Branch Pending Review
  • Assignee set to Nigel Kersten
  • Priority changed from Normal to High
  • Target version set to 2.7.x
  • Branch set to https://github.com/jcollie/puppet/tree/feature%2Fmaster%2F7999-systemd-services

Nigel – think this should go into a 2.7.x release?

#7
Updated by James Turnbull 9 months ago

Hey Jeff – could you send a pull request for your branch? Thanks.

#8
Updated by Jeff Ollie 9 months ago

Done:

https://github.com/puppetlabs/puppet/pull/102

#9
Updated by Jeff Ollie 9 months ago

Ooops, I requested the wrong branch be pulled, so I closed the old request and opened up a new one:

https://github.com/puppetlabs/puppet/pull/103

#10
Updated by James Turnbull 9 months ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release
  • Target version changed from 2.7.x to 2.7.4

Awesome that this is merged – thanks again to Jeff for the code.

#11
Updated by Matthaus Litteken 9 months ago

  • Status changed from Merged - Pending Release to Closed

Released in 2.7.4rc1

#12
Updated by John Florian 28 days ago

So glad to see this coming. I’ve been struggling to keep puppet and Fedora (15/16) playing well together, especially for services that don’t yet have native systemd support. The default ‘redhat’ provider does a ‘chkconfig SERVICE’ and I’ve found that many of these services can return the wrong exit code so puppet perpetually tries to re-enable them even though they are already enabled. Similar problems exist to determine if the service is currently running due to unexpected PID file locations or executable names that don’t match service names. Yuck!

A more ugly problem arose recently that I thought I’d share. Systemd abandons the notion of runlevels, but provides a way of emulating them, if desired. Thus it’s possible to have a typical graphical workstation have a default target (see /etc/systemd/system/default.target) of /lib/systemd/system/graphical.target or /lib/systemd/system/runlevel5.target. While the former is very similar to the latter, it seems that subtle differences between the two can influence the output of the ‘runlevel’ command and that in turn can influence the exit codes of the ‘chkconfig’ command, leading back to the problem I described in the first paragraph.

So many thanks to all for this work here!

Also available in: Atom PDF