Opened 5 years ago

Last modified 11 months ago

#12148 accepted Patch - Feature

Feature patch to support systemd ready notification in backend

Reported by: Gary Buhrmaster <gary.buhrmaster@…> Owned by: Karl Egly
Priority: minor Milestone: 29.2
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Feature patch to support systemd ready notification in backend

This is a feature patch to support the ability to use systemd After functionality for units that wish to wait until the backend has completed initialization.

Systemd is the system management daemon for many newer Linux distros. One of its features is the ability to have startup dependencies based on the the After option in a unit section. This feature patch adds in a call to the sd_notify function specifying that the backend process is READY after startup has completed. This will allow other systemd units to wait for the backend to complete initialization using the After (and a Requires if appropriate) unit options, or to test for the backend being ready via systemctl status (perhaps useful in a combined BE/FE situation where the FE wishes to wait for the BE to complete initialization).

Note that the sd_notify call is defined to be a no-op if the current system was not booted using systemd, making it (theoretically) safe to invoke sd_notify on platforms transitioning to systemd from alternative init systems.

The configure script is modified to autodetect (using pkg-config) the required functionality and libraries and default to enabling systemd ready notification if the build dependencies are met. A new configure option: --disable-systemd_notify is available to insure that support is not compiled into mythbackend if required.

(Lightly) tested in a development environment.

Release note item: Users/Packagers? using systemd may want to consider adding the new build requirements (systemd-devel) to enable support, and to change the Type from simple to notify in their service files.

github ref: https://github.com/garybuhrmaster/mythtv/commit/70293a6b766b3c761ba023d6f816e79c5d10de3d

github git-am ref: https://github.com/garybuhrmaster/mythtv/commit/70293a6b766b3c761ba023d6f816e79c5d10de3d.patch

Change History (9)

comment:1 Changed 3 years ago by Gary Buhrmaster <gary.buhrmaster@…>

In 229bca12a4102ad9af0ec1b7c9d3c9f1a4434245/mythtv:

ass support for systemd notify to mythbackend

Refs #12148
Patch by Gary Buhrmaster

(cherry picked from commit 70293a6b766b3c761ba023d6f816e79c5d10de3d)

Conflicts:

mythtv/configure

comment:2 Changed 3 years ago by Karl Egly

Milestone: unknown0.28
Owner: set to Karl Egly
Status: newaccepted

comment:3 Changed 3 years ago by Karl Egly

Hi Gary, sorry for taking so long to get this in. Should we add sd_notify to all our daemons?

comment:4 in reply to:  3 Changed 3 years ago by gary.buhrmaster@…

Replying to dekarl:

Hi Gary, sorry for taking so long to get this in. Should we add sd_notify to all our daemons?

No problem (it was a minor minor feature patch). As to adding to other daemons, I saw a clear use case for the BE (so scratched my itch). The other use cases that I can imagine now (but I did not come up with something concrete at the time) might be for mythmediaserver or mythjobqueue (but I will note the project does not even ship service files for those programs in the packaging repo (although some distros might)). I can see no reason not to add sd_notify to the service(s), nor not to provide service definitions, just for consistency. If you (or someone else) does not get to it I'll try to remember to add it to my list of things I would like to contribute to MythTV (eventually).

comment:5 Changed 3 years ago by Karl Egly

Milestone: 0.280.29

comment:6 Changed 3 years ago by Stuart Auchterlonie

Milestone: 0.2929.0

Milestone renamed

comment:7 Changed 13 months ago by Stuart Auchterlonie

Milestone: 29.029.1

comment:8 Changed 11 months ago by Stuart Auchterlonie

Milestone: 29.10.28.2

Moving remaining open tickets to 0.28.2 milestone

comment:9 Changed 11 months ago by Stuart Auchterlonie

Milestone: 0.28.229.2

Moving remaining open tickets to 29.2 milestone

Note: See TracTickets for help on using tickets.