docker-systemctl-replacement icon indicating copy to clipboard operation
docker-systemctl-replacement copied to clipboard

"Requires" not respected.

Open RafalJachimczyk opened this issue 4 years ago • 2 comments

Hi!

First of all - thanks for all the good work you're doing to bring this software to life.

In a standard systemd service definition, we can set the Requires= parameter and it does it's job of preventing the Requiring service to start if the Required service failed.

Now, I have replaced the standard systemd initialiser with docker-systemctl-replacement and was testing to see if the same can be achieved, but it does not look so. The service that Requires another service to start first, still starts (which we want to avoid).

Let's say this is the Required service config-bootstrapper.service :

[Unit]
Description=Envoy Proxy Config Bootstrapper
After=network.target
Before=envoy.service

And the Requiring service envoy.service:

[Unit]
Description=Envoy proxy
After=network.target
Requires=config-bootstrapper.service

I have tested and the above configuration works fine in standard systemd but not in the replacement. Is this intended/by design or a bug ?

I am not good with Python, but have found some mentions of Requires in your code, so maybe it is a bug?

Thanks, Rafal

RafalJachimczyk avatar Jun 21 '21 13:06 RafalJachimczyk

I think that is a feature being not implemented. Orginally the replacement script was just looking for services that are enabled, it does then figure out the order of starting them, and then runs them in that order. With the implemention of target units it can take the Requires attributes to serve in place of enabled-bits.

I'd say that the code has matured to a point that the behaviour you want can be implemented. But so far it was not attempted - atleast that's what the testsuite.py does say. I would integrate patches of course but I don't have a need for that personally.

gdraheim avatar Jul 05 '21 23:07 gdraheim

I had made some effort to implement proper dependency management but it did basically break the testsuite. You can find the code on branch v1.6 but I stopped developing it any further. The effort is too high while at the same time most container runtime engines have learned tricks to run systemd services directly.

gdraheim avatar Jul 28 '23 20:07 gdraheim