[dev.icinga.com #4794] add systemd support

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/4794

Created by mfriedrich on 2013-10-01 17:14:29 +00:00

Assignee: shk
Status: Resolved (closed on 2014-06-15 18:30:03 +00:00)
Target Version: 2.0.0
Last Update: 2014-06-15 18:30:03 +00:00 (in Redmine)

---

Changesets

2014-04-30 23:48:01 +00:00 by gvegidy 9b138fb

First try at a systemd service definition file, install it from CMake.

Native systemd support is enabled with cmake -DUSE_SYSTEMD=ON

Refs #4794

2014-05-04 18:46:13 +00:00 by gvegidy 0530984

Fix CMake escaping.

Refs #4794

2014-05-04 20:32:44 +00:00 by gvegidy f7f3f64

Systemd can't resolve variables recursively.

Refs #4794

2014-05-18 19:45:21 +00:00 by gvegidy 5802619

First try at a systemd service definition file, install it from CMake.

Native systemd support is enabled with cmake -DUSE_SYSTEMD=ON

Refs #4794

2014-05-18 19:45:39 +00:00 by gvegidy 3c98e40

Fix CMake escaping.

Refs #4794

2014-05-18 19:45:57 +00:00 by gvegidy 881d9cc

Systemd can't resolve variables recursively.

Refs #4794

2014-05-18 19:49:08 +00:00 by gvegidy 8c74a00

Reloading with systemd is fixed now.

Refs #4794

2014-05-18 20:47:27 +00:00 by gvegidy 3bdf4b1

Unify resources for SysV-Init and systemd.

- Move system-specific defines like paths and usernames to /etc/icinga2/sysdefines.conf
  Do not use /etc/sysconfig for this as per suggestion on the systemd mailinglist: it is RedHat-specific
- Use /etc/icinga2/sysdefines.conf in SysV-Init and systemd
- Move both the sources of the SysV-Initscript and the systemd-service definition to etc/initsystem

Refs #4794

2014-05-18 21:14:30 +00:00 by gvegidy 5c2ee93

Move code preparing dirs and permissions to icinga2-prepare-dirs, use this for SysV-Init and systemd.

Refs #4794

2014-05-26 23:05:25 +00:00 by gvegidy 384f4c7

First try at adding systemd detection to the .spec file.

Handling of %post, %postun,... still missing - this is done differently on Redhat and Suse plattforms.

Refs #4794

2014-06-15 13:30:53 +00:00 by gvegidy 69c0611

First try at a systemd service definition file, install it from CMake.

Native systemd support is enabled with cmake -DUSE_SYSTEMD=ON

Refs #4794

2014-06-15 13:31:10 +00:00 by gvegidy 954ceb3

Fix CMake escaping.

Refs #4794

2014-06-15 13:31:32 +00:00 by gvegidy 7bfd2f1

Systemd can't resolve variables recursively.

Refs #4794

2014-06-15 13:32:13 +00:00 by gvegidy 59a1a13

Reloading with systemd is fixed now.

Refs #4794

2014-06-15 13:49:13 +00:00 by gvegidy ef49658

Unify resources for SysV-Init and systemd.

- Move system-specific defines like paths and usernames to /etc/icinga2/sysdefines.conf
  Do not use /etc/sysconfig for this as per suggestion on the systemd mailinglist: it is RedHat-specific
- Use /etc/icinga2/sysdefines.conf in SysV-Init and systemd
- Move both the sources of the SysV-Initscript and the systemd-service definition to etc/initsystem

Refs #4794

Conflicts:
	etc/initsystem/icinga2.init.d.cmake

2014-06-15 14:25:50 +00:00 by gvegidy 4ebde46

Move code preparing dirs and permissions to icinga2-prepare-dirs, use this for SysV-Init and systemd.

Refs #4794

Conflicts:
	etc/initsystem/icinga2.init.d.cmake

2014-06-15 14:56:22 +00:00 by (unknown) 6a52097

Generate the service unit on Fedora and use the %systemd_post/_postun/_preun macros for service setup

Refs #4794

2014-06-15 15:00:30 +00:00 by (unknown) 4568f68

Remove mention of icinga in the description since it's already in the name and might cause versioning confusion

Refs #4794

2014-06-15 15:25:27 +00:00 by gvegidy 83528f6

Move decision about systemd/sysvinit to one location. Add files forgotten during merge.

Refs #4794

2014-06-15 17:47:27 +00:00 by gvegidy dd9b7bc

Move the sysdefines.conf file to /etc/sysconfig.

As /etc/sysconfig is distro specific, the filename used can be configured via the CMake parameter
ICINGA2_SYSCONFIGFILE

Refs #4794

2014-06-15 18:01:04 +00:00 by gvegidy 39150ca

Add a manpage for icinga2-prepare-dirs.

Refs #4794

2014-06-15 18:08:05 +00:00 by gvegidy 5b8b85d

Don't mark the systemd service file as executable.

Refs #4794

2014-06-15 18:08:45 +00:00 by gvegidy fe62fb9

Don't call check_run in the initscript, this function is gone.

Refs #4794

2014-06-15 18:23:03 +00:00 by (unknown) 3d8d8dc

install new man page properly

refs #4794

2014-06-15 18:27:15 +00:00 by mfriedrich 61793a5

Merge branch 'feature/systemd-4794-final' into next

fixes #4794

---

Subtasks:

• Feature 6118 - reloading icinga2 doesn't work when run as a native systemd service

[icinga-migration]

Updated by mfriedrich on 2013-10-22 09:03:55 +00:00

• Target Version deleted 0.0.4

[icinga-migration]

Updated by mfriedrich on 2014-04-29 15:47:20 +00:00

• Assigned to changed from mfriedrich to shk
• Target Version set to 2.0 Beta 1

@sam

could you look into that? :)

[icinga-migration]

Updated by gvegidy on 2014-04-29 21:05:39 +00:00

I can help with this if you want to

[icinga-migration]

Updated by shk on 2014-04-30 03:37:42 +00:00

Yep, I'll start on this today. @gvegidy do you have commit or just wanna handle things through patches once I start my branch?

[icinga-migration]

Updated by gvegidy on 2014-04-30 06:08:42 +00:00

I have commit access, so I can add to your branch. But I won't have time to work on this until this evening (Germany) or tomorrow. So just start your branch and I'll see if and how I can help.

[icinga-migration]

Updated by shk on 2014-04-30 08:50:05 +00:00

I've started working here - https://git.icinga.org/?p=icinga2.git;a=shortlog;h=refs/heads/feature/systemd-4794. Can you please ping me on IRC or here when you've got a bit of free time so we can sync up and split the work between us?

[icinga-migration]

Updated by gvegidy on 2014-05-01 00:05:36 +00:00

Hi Sam,

I added a first rough version of a systemd service definition file for icinga2. I also added a CMake option to switch between classic init.d and systemd. I think autodetecting systemd vs. classic init is not a good idea because maybe the disto you want to build for is currently in transition to systemd and has it installed, but doesn't use it yet. So in the end the package maintainer should decide what to use by setting the correct cmake switch.

Here some rough ideas what we should do:

• I moved the variables that are traditionally at the beginning of the initscript to /etc/sysconfig/icinga2. I think it would be best to use this file both for systemd and classic init.d

• Before the initscript starts the daemon, it creates log dirs, checks their permissions and so on. We should move that to a separate script and call it both from the initscript and ExecStartPre

• review the cmake stuff I added, that was just a quick copy & paste hack

• install the systemd-stuff in the .spec. Add a config switch to the .spec allowing to enable and disable the use of systemd and set the defaults correctly depending on the distro we are building for

• reload through systemd is broken. This seems to be a very annoying part of systemd, I already had trouble with this while working on #5788.

[icinga-migration]

Updated by shk on 2014-05-01 00:56:53 +00:00

gvegidy wrote:

Hi Sam,

I added a first rough version of a systemd service definition file for icinga2. I also added a CMake option to switch between classic init.d and systemd. I think autodetecting systemd vs. classic init is not a good idea because maybe the disto you want to build for is currently in transition to systemd and has it installed, but doesn't use it yet. So in the end the package maintainer should decide what to use by setting the correct cmake switch.

Here some rough ideas what we should do:

• I moved the variables that are traditionally at the beginning of the initscript to /etc/sysconfig/icinga2. I think it would be best to use this file both for systemd and classic init.d

• Before the initscript starts the daemon, it creates log dirs, checks their permissions and so on. We should move that to a separate script and call it both from the initscript and ExecStartPre

• review the cmake stuff I added, that was just a quick copy & paste hack

• install the systemd-stuff in the .spec. Add a config switch to the .spec allowing to enable and disable the use of systemd and set the defaults correctly depending on the distro we are building for

That isn't really the right way to handle systemd requirements and the installation of service units. Each platform which supports systemd will provide macros for when it should be used. Making this a cmake option just makes the build process even more complicated and we should avoid that.

I don't want to change your work with your permission, but I'd like to (at least mostly) follow the guidelines provided by the OS's around how and when to use systemd vs. sysvinit. Is it okay if I change what you did a little bit?

• reload through systemd is broken. This seems to be a very annoying part of systemd, I already had trouble with this while working on #5788.

[icinga-migration]

Updated by gvegidy on 2014-05-01 11:14:15 +00:00

shk wrote:

> - install the systemd-stuff in the .spec. Add a config switch to the .spec allowing to enable and disable the use of systemd and set the defaults correctly depending on the distro we are building for

That isn't really the right way to handle systemd requirements and the installation of service units. Each platform which supports systemd will provide macros for when it should be used.

Hmm, on second thought I think you are right, an externally available config switch in the .spec is not a good idea. Using the rpm-macros in the spec to make the decision is better.

Making this a cmake option just makes the build process even more complicated and we should avoid that.

But I still think that the init/systemd decision should be told cmake (e.g. via an option as I implemented it), and let cmake install the correct file. This is why:

• the service definition file has some paths in it, these are set through cmake. So the service definition file is not static, but needs to be handled by cmake anyway. So not much added complexity just by making it optional.
• running "make install" (without any kind of packaging) should result in a working and sane icinga, not missing any components like service definitions.
• cmake should not output the init-file and the service definition at the same time as this will lead to conflicts
• installing the service definition through cmake makes it easily available to all kinds of packaging systems, not just rpm

But maybe I'm not understanding what you had in mind. Could you describe how you had planned to provide and install the service definition and why doing it through cmake complicates this?

I don't want to change your work with your permission, but I'd like to (at least mostly) follow the guidelines provided by the OS's around how and when to use systemd vs. sysvinit. Is it okay if I change what you did a little bit?

Go ahead. This is git after all - nothing is lost. We should just reach a consensus how we want to implement it.

How about my other points? Do you agree to all of them?

[icinga-migration]

Updated by shk on 2014-05-01 15:31:34 +00:00

gvegidy wrote:

shk wrote:
> > - install the systemd-stuff in the .spec. Add a config switch to the .spec allowing to enable and disable the use of systemd and set the defaults correctly depending on the distro we are building for
>
> That isn't really the right way to handle systemd requirements and the installation of service units. Each platform which supports systemd will provide macros for when it should be used.

Hmm, on second thought I think you are right, an externally available config switch in the .spec is not a good idea. Using the rpm-macros in the spec to make the decision is better.

> Making this a cmake option just makes the build process even more complicated and we should avoid that.

But I still think that the init/systemd decision should be told cmake (e.g. via an option as I implemented it), and let cmake install the correct file. This is why:

• the service definition file has some paths in it, these are set through cmake. So the service definition file is not static, but needs to be handled by cmake anyway. So not much added complexity just by making it optional.
• running "make install" (without any kind of packaging) should result in a working and sane icinga, not missing any components like service definitions.
• cmake should not output the init-file and the service definition at the same time as this will lead to conflicts
• installing the service definition through cmake makes it easily available to all kinds of packaging systems, not just rpm

But maybe I'm not understanding what you had in mind. Could you describe how you had planned to provide and install the service definition and why doing it through cmake complicates this?

No, I think you're right in the approach so far to generate the service unit based on the path. I was mainly opposed to the flag in the spec. +1.

> I don't want to change your work with your permission, but I'd like to (at least mostly) follow the guidelines provided by the OS's around how and when to use systemd vs. sysvinit. Is it okay if I change what you did a little bit?

Go ahead. This is git after all - nothing is lost. We should just reach a consensus how we want to implement it.

Just wanted to make sure before changing your work :-)

How about my other points? Do you agree to all of them?

[icinga-migration]

Updated by gvegidy on 2014-05-01 15:56:41 +00:00

shk wrote:

No, I think you're right in the approach so far to generate the service unit based on the path. I was mainly opposed to the flag in the spec. +1.

Very good.

I tried several ways to get reload working and didn't succeed yet. I think I'll have to contact the systemd developer list and ask for guidance.

And there seems to be a problem with escaping the variables in the service definition, currently cmake removes them. I haven't looked into this yet. I think I'll concentrate on the reload stuff first because I fear this could become a tough nut to crack.

[icinga-migration]

Updated by gvegidy on 2014-05-18 21:40:03 +00:00

I fixed the reload issue, this code is already merged into git-next. I created a new branch, systemd-4794-rebase, containing the previous stuff, but rebased on top of git-next. I then added the things I thought necessary for systemd support and some of the suggestions I got from the systemd-devel list. So from my side everything except the packaging is done.

I won't have time do further work on this for the next few days.

Sam, could you please do a short review of my init-shuffling and then look at packaging. Thanks.

[icinga-migration]

Updated by shk on 2014-05-18 21:55:07 +00:00

I'll finish the packaging work either tomorrow or Tuesday. Thanks!

[icinga-migration]

Updated by gvegidy on 2014-05-23 21:26:51 +00:00

Do you want to do this or should I take a look at the packaging this weekend? I'd like to see systemd support in the beta1.

[icinga-migration]

Updated by mfriedrich on 2014-05-26 11:52:06 +00:00

Any updates on this?

[icinga-migration]

Updated by mfriedrich on 2014-05-26 19:00:34 +00:00

• Target Version changed from 2.0 Beta 1 to 2.0 Beta 2

[icinga-migration]

Updated by mfriedrich on 2014-06-05 09:13:22 +00:00

• Target Version changed from 2.0 Beta 2 to 2.0.0

[icinga-migration]

Updated by mfriedrich on 2014-06-13 07:51:26 +00:00

Could you please coordinate on this with @TheH, and give a final state before staturday evening (CEST) how and if this is ready for 2.0.0? Thanks.

[icinga-migration]

Updated by gvegidy on 2014-06-13 09:53:03 +00:00

there are currently two branches for this, both have some parts we need. I planned to consolidate them into one, based on current git-next, but didn't have the time yet. I plan to to this this evening or saturday.

[icinga-migration]

Updated by mfriedrich on 2014-06-15 00:38:08 +00:00

any news?

[icinga-migration]

Updated by mfriedrich on 2014-06-15 18:30:03 +00:00

• Status changed from Assigned to Resolved

Applied in changeset 61793a5.