Systemd programming part 2: activation and language issues [LWN.net]

Systemd programming part 2: activation and language issues

Posted Feb 20, 2014 11:12 UTC (Thu) by kevinm (guest, #69913)
Parent article: Systemd programming part 2: activation and language issues

It seems unfortunate that the concept of whether a service is administratively disabled or enabled is apparently conflated with codifying the dependencies between services.

The dependencies are quite static and rarely changed, presumably set by upstream and tweaked by the builder of your distribution. However services may be enabled and disabled frequently as a matter of administrative fiat.

to post comments

Systemd programming part 2: activation and language issues

Posted Feb 20, 2014 14:30 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Hmm? Could you be more specific? Sometimes dependencies are configuration-related. For example, I run nginx in front of any service which uses a web interface. How would flyspray know that its configuration needs to start nginx first to actually work? In systemd, I could just enable it by symlinking nginx into fastcgiwrap@flyspray.service.wants without modifying any service files (though in reality I'd use socket activation). How would you do such a dependency in other systems?

Systemd programming part 2: activation and language issues

Posted Feb 20, 2014 17:03 UTC (Thu) by cg909 (guest, #95647) [Link]

Systemd has another way to explicity disable a service:
systemctl mask $service
That tells systemd that this service should never run.

In the systemd concept every service that is known to systemd *may* be started if its needed (and is not masked).

systemctl enable $service can be read as "Make sure that $service *will* be run."

So with systemd you have in fact more flexibility: You can leave a service disabled, so that it will run only if required by another unit; you can enable it to let it run in any case and you can mask it to disable it completely.