Project

General

Profile

Architecture #3828

Adapt Techniques so they use available init system on each Node

Added by Michael Gliwinski about 5 years ago. Updated almost 4 years ago.

Status:
Released
Priority:
1
Assignee:
Matthieu CERDA
Category:
Techniques
Target version:
Target version (plugin):
Effort required:
Pull Request:

Description

This applies to servicesManagement technique as well as other techniques that internally start/stop/restart services (e.g. cronManagement, nfsServer, sshConfiguration, clockConfiguration, apacheServer, system/common, etc.).

Specifically, it is assumed that /etc/init.d/$SERVICE script can be used to control the service, which is not always true.

The /etc/init.d script method won't work if the service isn't a sysv service but e.g. an upstart job. So far this hasn't been causing many issues as upstart is mainly used on ubuntu where packages redirect their /etc/init.d/$SERVICE to call appropriate upstart command. However support for upstart jobs is being slowly merged into Debian and since Ubuntu Saucy calling /etc/init.d/$SERVICE for a service managed by upstart will be an error. In fact Debian policy recommends using "service" script (or "invoke-rc.d" - for maintainer scripts) which abstracts the differences and handles calling the correct command internally.

See https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037150.html

Using the "service" script would seem like a better option. Still there are two problems: on RedHat/CentOS the script doesn't actually handle upstart jobs (this is an upstream issue though, I think I'll report it there), and the script location needs to be abstracted (it's in /sbin/service on RHEL/CentOS and in /usr/sbin/service on Debian/Ubuntu).

What do you think?


Subtasks

Architecture #5845: Add support for systemd in the Techniques (Non system ones)ReleasedJonathan CLARKE
Architecture #5846: Add support for systemd in the Techniques (System ones)ReleasedJonathan CLARKE

Related issues

Related to Rudder - User story #5469: RHEL/CentOS 7 packagesReleased2014-09-12
Has duplicate Rudder - User story #5451: Add support for systemd in the TechniquesRejected

History

#1 Updated by Vincent MEMBRÉ about 5 years ago

  • Assignee set to Jonathan CLARKE

I think there should be an abstraction over it and Rudder should use the right system in any cases.

That would imply to change the way we handle service management. (checking if the node uses systemd or not).

I think we need to create a specific bundle taking a service as parameter that would check the system behavior before restarting it.

I don't know if this is a bug, or a complete change in how we handle service, and as a consequence more a User Story.

Jon, Matthieu or Nicolas, what is your opinion about that ?

#2 Updated by Michael Gliwinski about 5 years ago

Vincent MEMBRÉ wrote:

I think there should be an abstraction over it and Rudder should use the right system in any cases.

Yeah, that's what I wasn't sure about myself. Technically, we could rely on facilities in the distro that abstract the differences (like the "service" script). The only problem with that is not all distros provide proper working abstraction. It could be argued that it should be fixed there though :)

That would imply to change the way we handle service management. (checking if the node uses systemd or not).

I think we need to create a specific bundle taking a service as parameter that would check the system behavior before restarting it.

Another complication is that this checking would need to be done per-service, as I'm not sure about systemd, but e.g. upstart still supports old SysV scripts, so effectively it could be a mixed system. Also in Debian, I believe the idea is that you will be able to switch between them (i.e. which one is your main init system).

I don't know if this is a bug, or a complete change in how we handle service, and as a consequence more a User Story.

Jon, Matthieu or Nicolas, what is your opinion about that ?

#3 Updated by Vincent MEMBRÉ about 5 years ago

  • Assignee changed from Jonathan CLARKE to Matthieu CERDA

I think there should be a way to determine what system is used...

An other solution would be to let the choice in each technique (a list where you have to choose the right system ...)

Matthieu will look into this and find out what is the best option for us.

#4 Updated by Matthieu CERDA over 4 years ago

  • Status changed from New to In progress
  • Priority changed from N/A to 1
  • Target version set to 2.10.0~beta1

Well, after testing on all the systems we support, it seems using "service" is the best way to go, as it supports either sysvinit, Upstart or systemd without problems.

Anyway, I will declare it as a global variable in site.st, this way we will always have a way of changing it easily if needed one day.

But, I hope everything will be ported to ncf beforehand :)

#5 Updated by Matthieu CERDA over 4 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Matthieu CERDA to Jonathan CLARKE
  • % Done changed from 0 to 100
  • Pull Request set to https://github.com/Normation/rudder-techniques/pull/313

PR ready

#6 Updated by Jonathan CLARKE over 4 years ago

  • Status changed from Pending technical review to 8
  • Assignee changed from Jonathan CLARKE to Matthieu CERDA
  • Target version changed from 2.10.0~beta1 to 2.11.0~beta1
  • % Done changed from 100 to 0
  • Pull Request deleted (https://github.com/Normation/rudder-techniques/pull/313)

Matthieu CERDA wrote:

Well, after testing on all the systems we support, it seems using "service" is the best way to go, as it supports either sysvinit, Upstart or systemd without problems.

Anyway, I will declare it as a global variable in site.st, this way we will always have a way of changing it easily if needed one day.

As discussed, this is not a good long-term approach: it will not work on a system like AIX, and does not go in the factorise-in-bundles direction we are taking globally.

Matthieu, please rework this to call a service_{restart,reload,start,etc} bundle each time it's necessary.

#7 Updated by Jonathan CLARKE over 4 years ago

  • Target version changed from 2.11.0~beta1 to 140

#8 Updated by Matthieu CERDA almost 4 years ago

  • Target version changed from 140 to 3.0.0~beta1

#9 Updated by Jonathan CLARKE almost 4 years ago

  • Tracker changed from Bug to Architecture
  • Subject changed from Techniques assume services are managed by SystemV init to Techniques should not assume services are managed by SystemV init
  • Status changed from 8 to Discussion

This has been completely reworked in the sub tickets. Rudder 3.0.0 supports systemd, systemctl, init.d, depending on what is available.

#10 Updated by Jonathan CLARKE almost 4 years ago

  • Status changed from Discussion to 12

#11 Updated by Jonathan CLARKE almost 4 years ago

  • Status changed from 12 to Pending release

#12 Updated by Vincent MEMBRÉ almost 4 years ago

  • Subject changed from Techniques should not assume services are managed by SystemV init to Adapt Techniques so they use available init system on Node

#13 Updated by Vincent MEMBRÉ almost 4 years ago

  • Subject changed from Adapt Techniques so they use available init system on Node to Adapt Techniques so they use available init system on each Node

#14 Updated by Vincent MEMBRÉ almost 4 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 3.0.0~beta1 which was release on 01/12/2014.

Also available in: Atom PDF