On 10.04.2021 03:07, Cameron Sparr wrote: > Hello, I work for Amazon ECS and I’ve been working on a change to one of our > systemd services. From what I could tell in documentation I found online, it > seemed that RequiresOverridable= was the perfect fit for our use-case. > > > When I built a package using this field, however, I got a message saying that > this option is obsolete, which led me to this mailing list message: > https://lists.freedesktop.org/archives/systemd-devel/2015-November/034880.html > > > So my question is, what would be the alternative to using > RequiresOverridable? What got our attention to use this flag was that user > input would be able to override the requirement, which is exactly what we > want. Does Requires= also provide that capability? From our testing it > _seems_ like it does but I don’t see it called out in the documentation > anywhere. > > > If it helps, I can describe our use-case below: > > > 1. We have a service that executes user-defined bash scripts on system > startup called (simplifying) cloud-final.service. > > 2. We have a service called ecs.service that runs the ecs daemon > service. This service’s configuration file is usually made by the user > scripts run in cloud-final.service > > 3. So we wanted to make sure ecs.service starts after > cloud-final.service. To accomplish this we put After=cloud-final.service in > ecs.service. > > 4. But now we would also like users to be able to override ecs.service > waiting for cloud-final.service to finish. Because cloud-final allows users > to execute arbitrary bash scripts they should be able to run “systemctl start > ecs” and the ecs service will start. >
After= dependencies are relevant only for jobs that are currently present in job queue. If ecs.server does not pull in cloud-final.service with Wants= or Requires=, you can start it explicitly without any delay. Of course if when you request starting ecs.service the cloud-final.service is still being activated (its start job is active), then ecs.service will wait for activation to complete. There is no way around it I am aware of. > 5. So the solution we were going to do was split ecs into two services: > > a. ecs-ready.service which has After=cloud-final.service > > b. ecs.service which has RequiresOverridable=ecs-ready.service > Requires/Wants/RequiresOverridable= without After= is useless. And it sounds like you tested Requires= without After= when you say "it seems to work". RequiresOverridable= with After= would still attempt to start required unit and wait for it. It would have ignored failure to start required unit, but that is not what you want. > 6. The idea above being that normally ecs.service would start with > ecs-ready (and thus after cloud-final), but if the user explicitly requested > it could be started without having to wait for after cloud-final. > > > > _______________________________________________ > systemd-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
