using SYSTEMD_SERVICE to disable a systemd service?


Robert P. J. Day
 

while the "standard" way to disable a systemd service from
auto-booting is SYSTEMD_AUTO_ENABLE, i just ran across a number of
examples in an existing project that do this:

SYSTEMD_SERVICE_${PN} = ""

ouch. that's a new one on me and, while i'm prepared to believe it
works, it seems like grotesque overkill and mis-application of that
variable.

am i within my rights to suggest that that's not really the way to
do it? or is that considered an acceptable (albeit weird) alternative?

rday


Mikko Rapeli
 

Hi,

On Tue, Feb 02, 2021 at 03:38:34AM -0500, Robert P. J. Day wrote:

while the "standard" way to disable a systemd service from
auto-booting is SYSTEMD_AUTO_ENABLE, i just ran across a number of
examples in an existing project that do this:

SYSTEMD_SERVICE_${PN} = ""

ouch. that's a new one on me and, while i'm prepared to believe it
works, it seems like grotesque overkill and mis-application of that
variable.

am i within my rights to suggest that that's not really the way to
do it? or is that considered an acceptable (albeit weird) alternative?
We do SYSTEMD_SERVICE_${PN} = "" a lot but reasons are a lot more complex.

To properly tune target system boot, one really needs to fork most systemd service
files. This is needed to set cgroups, permissons, to change service and/or
target dependencies e.g. additional or intermediate boot targets.

Thus one ends up forking most of the service files. For some subset, it's enough
to patch them, but for most it's easier to just fork even the ones that come from systemd.
Additionally a lot of testing and logging infra needs to be added to make sure boot is
clean and happens the way developers designed and meets the KPIs like boot time.

These are tricky to maintain and so company/industry/product/version specific that
it's tricky to upstream the changes.

Cheers,

-Mikko