On 10.04.2021 21:54, Cameron Sparr wrote: >> Requires/Wants/RequiresOverridable= without After= is useless. > > Thanks for the reply. I'm curious about this statement, do you mean it is > useless in general without After= or just in the context of our use-case? >
General. Read man systemd.unit, read this list archives - this question pops up every month. Requires= is useless to define startup dependencies unless you can ensure that start job for required unit completes (successfully or not) before start job for requiring unit is selected for processing. > I should probably clarify the use-case too. cloud-final.service runs after > cloud-init.service finishes. So if ecs.service starts at the same time as > cloud-final.service this is acceptable. Is this the behavior that Requires= > alone gives us? I do not understand this question. And if I understand correctly it can be overridden if the user explicitly starts ecs.service using 'systemctl start' ? > Requires= cannot be overridden. > On 4/9/21, 11:45 PM, "systemd-devel on behalf of Andrei Borzenkov" > <[email protected] on behalf of > [email protected]> wrote: > > 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 > > _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
