Discussion:
[systemd-devel] Alternatives to RequiresOverridable= ?
Cameron Sparr
2021-04-10 00:07:12 UTC
Permalink
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.

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

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.
Andrei Borzenkov
2021-04-10 05:37:40 UTC
Permalink
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.
 
 
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.
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Cameron Sparr
2021-04-10 18:54:45 UTC
Permalink
Post by Andrei Borzenkov
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?

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? And if I understand correctly it can be overridden if the user explicitly starts ecs.service using 'systemctl start' ?
Post by Andrei Borzenkov
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.
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.
Post by Andrei Borzenkov
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.
Post by Andrei Borzenkov
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
systemd-***@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Andrei Borzenkov
2021-04-11 04:59:57 UTC
Permalink
Post by Cameron Sparr
Post by Andrei Borzenkov
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.
Post by Cameron Sparr
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.
Post by Cameron Sparr
Post by Andrei Borzenkov
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.
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.
Post by Andrei Borzenkov
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.
Post by Andrei Borzenkov
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Loading...