Re: [systemd-devel] Alternatives to RequiresOverridable= ?
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" > arvidj...@gmail.com> 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 > > systemd-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alternatives to RequiresOverridable= ?
> 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' ? On 4/9/21, 11:45 PM, "systemd-devel on behalf of Andrei Borzenkov" 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 > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Storing package metadata in ELF objects
[I'm forwarding the mail from Luca who is not subscribed to fedora-devel] On Sat, Apr 10, 2021 at 01:38:31PM +0100, Luca Boccassi wrote: Hello, Cross-posting to the mailing lists of a few relevant projects. After an initial discussion [0], recently we have been working on a new specification [0] to encode rich package-level metadata inside ELF objects, so that it can be included automatically in generated coredump files. The prototype to parse this in systemd-coredump and store the information in systemd-journal is ready for testing and merged upstream. We are now seeking further comments/opinions/suggestions, as we have a few months before the next release and thus there's plenty of time to make incompatible changes to the format and implementation, if required. A proposal to use this by default for all packages built in Fedora 35 has been submitted [1]. The Fedora Wiki and the systemd.io document have more details, but to make a long story short, a new .notes.package section with a JSON payload will be included in ELF objects, encoding various package- build-time information like distro name&version, package name&version, etc. To summarize from the discussion, the main reasons why we believe this is useful are as following: 1) minimal containers: the rpm database is not installed in the containers. The information about build-ids needs to be stored externally, so package name information is not available immediately, but only after offline processing. The new note doesn't depend on the rpm db in any way. 2) handling of a core from a container, where the container and host have different distros 3) self-built and external packages: unless a lot of care is taken to keep access to the debuginfo packages, this information may be lost. The new note is available even if the repository metadata gets lost. Users can easily provide equivalent information in a format that makes sense in their own environment. It should work even when rpms and debs and other formats are mixed, e.g. during container image creation. Other than in Fedora, we are already making the required code changes at Microsoft to use the same format&specification for internally-built binaries, and for tools that parse core files and logs. Tools for RPM and DEB (debhelper) integration are also available [3]. > -- > Kind regards, > Luca Boccassi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bitcoind.service activation problem
I guess it's ok to ask such question on this mailing list, as it is rather low traffic. That said, more details are always better. So instead of a screenshot, include a full copy of the service files and the full status and/or journalctl -u bitcoind.service output. This is either a configuration problem or the service file does not have the proper Type= Am Sa., 10. Apr. 2021 um 15:36 Uhr schrieb Tomasz Torcz : > > Dnia Sat, Apr 10, 2021 at 05:39:34PM +0600, Shafiun Miraz napisał(a): > > [image: image.png] > > [image: image.png] > > I am getting this error. Please someone help me! > > Hey Shafiun, couple of notes: > > - sending screenshots is not helpful, please just copy the message next > time; > > - there are no actual information why bitcoind.service is not starting. > Use "systemctl status bitcoind" to see more information and logs > related to the bitcoind.service. You can also use > "journalctl -u bitcoind.service" to see full logs. > > I expect startup problem is connected to bitcoind's configuration, but > without logs it's only guesswork. > > - finally, this is not a correct place to get support. Please open a bug > with your Linux Distribution and ask them to replace systemd-devel URL > with real support address (bugzilla, forum, github issues etc.). > This way users will get quicker support in the future. > > -- > Tomasz TorczOnly gods can safely risk perfection, > to...@pipebreaker.pl it's a dangerous thing for a man. — Alia > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bitcoind.service activation problem
Dnia Sat, Apr 10, 2021 at 05:39:34PM +0600, Shafiun Miraz napisał(a): > [image: image.png] > [image: image.png] > I am getting this error. Please someone help me! Hey Shafiun, couple of notes: - sending screenshots is not helpful, please just copy the message next time; - there are no actual information why bitcoind.service is not starting. Use "systemctl status bitcoind" to see more information and logs related to the bitcoind.service. You can also use "journalctl -u bitcoind.service" to see full logs. I expect startup problem is connected to bitcoind's configuration, but without logs it's only guesswork. - finally, this is not a correct place to get support. Please open a bug with your Linux Distribution and ask them to replace systemd-devel URL with real support address (bugzilla, forum, github issues etc.). This way users will get quicker support in the future. -- Tomasz TorczOnly gods can safely risk perfection, to...@pipebreaker.pl it's a dangerous thing for a man. — Alia ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] .local searches not working
On Fr, 09.04.21 15:20, Phillip Susi (ph...@thesusis.net) wrote: > > Silvio Knizek writes: > > > So in fact your network is not standard conform. You have to define > > .local as search and routing domain in the configuration of sd- > > resolved. > > Interesting... so what are you supposed to name your local, private > domains? This draft RFC suggests .home or .corp: https://www.ietf.org/archive/id/draft-chapin-additional-reserved-tlds-02.txt It never made it beyond a draft, but I think that#s already enough to be pretty sure these domains unlikely will be used elsewhere. RFC 6762, Appendix G suggests using .lan, .intranet, .internal and .private. RFC 8375 suggests .home.arpa. This is probably the RFC that is the most official one, but OTOH its probably at the moment the least widely used one. Still, probably the safest bet, though it does sound a bit weird when used in a corporate context. > I believe Microsoft used to ( or still do? ) recommend using > .local to name your domain if you don't have a public domain name, so > surely I'm not the first person to run into this? Why does > systemd-resolved not fall back to DNS if it can't first resolve the name > using mDNS? That appears to be allowed by the RFC. You can enable this, just add ~local to the routing domains of the relevant DNS server. We won't do this automatically for security reasons, as locally scoped names should not be routed to Internet DNS servers, as that leaks pretty sensitive information about the local network infrastructur Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Storing package metadata in ELF objects
On Sat, 2021-04-10 at 13:29 +0100, Luca Boccassi wrote: > Hello, > > Cross-posting to the mailing lists of a few relevant projects. > > After an initial discussion [0], recently we have been working on a new > specification [0] to encode rich package-level metadata inside ELF > objects, so that it can be included automatically in generated coredump > files. The prototype to parse this in systemd-coredump and store the > information in systemd-journal is ready for testing and merged > upstream. We are now seeking further comments/opinions/suggestions, as > we have a few months before the next release and thus there's plenty of > time to make incompatible changes to the format and implementation, if > required. > > A proposal to use this by default for all packages built in Fedora 35 > has been submitted [1]. > > The Fedora Wiki and the systemd.io document have more details, but to > make a long story short, a new .notes.package section with a JSON > payload will be included in ELF objects, encoding various package- > build-time information like distro name&version, package name&version, > etc. > > To summarize from the discussion, the main reasons why we believe this > is useful are as following: > > 1) minimal containers: the rpm database is not installed in the > containers. The information about build-ids needs to be stored > externally, so package name information is not available immediately, > but only after offline processing. The new note doesn't depend on the > rpm db in any way. > > 2) handling of a core from a container, where the container and host > have different distros > > 3) self-built and external packages: unless a lot of care is taken to > keep access to the debuginfo packages, this information may be lost. > The new note is available even if the repository metadata gets lost. > Users can easily provide equivalent information in a format that makes > sense in their own environment. It should work even when rpms and debs > and other formats are mixed, e.g. during container image creation. > > Other than in Fedora, we are already making the required code changes > at Microsoft to use the same format&specification for internally-built > binaries, and for tools that parse core files and logs. > > Tools for RPM and DEB (debhelper) integration are also available [3]. Wrong Fedora list address - off to a great start already :-) (fixed now) -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Storing package metadata in ELF objects
Hello, Cross-posting to the mailing lists of a few relevant projects. After an initial discussion [0], recently we have been working on a new specification [0] to encode rich package-level metadata inside ELF objects, so that it can be included automatically in generated coredump files. The prototype to parse this in systemd-coredump and store the information in systemd-journal is ready for testing and merged upstream. We are now seeking further comments/opinions/suggestions, as we have a few months before the next release and thus there's plenty of time to make incompatible changes to the format and implementation, if required. A proposal to use this by default for all packages built in Fedora 35 has been submitted [1]. The Fedora Wiki and the systemd.io document have more details, but to make a long story short, a new .notes.package section with a JSON payload will be included in ELF objects, encoding various package- build-time information like distro name&version, package name&version, etc. To summarize from the discussion, the main reasons why we believe this is useful are as following: 1) minimal containers: the rpm database is not installed in the containers. The information about build-ids needs to be stored externally, so package name information is not available immediately, but only after offline processing. The new note doesn't depend on the rpm db in any way. 2) handling of a core from a container, where the container and host have different distros 3) self-built and external packages: unless a lot of care is taken to keep access to the debuginfo packages, this information may be lost. The new note is available even if the repository metadata gets lost. Users can easily provide equivalent information in a format that makes sense in their own environment. It should work even when rpms and debs and other formats are mixed, e.g. during container image creation. Other than in Fedora, we are already making the required code changes at Microsoft to use the same format&specification for internally-built binaries, and for tools that parse core files and logs. Tools for RPM and DEB (debhelper) integration are also available [3]. -- Kind regards, Luca Boccassi [0] https://github.com/systemd/systemd/issues/18433 [1] https://systemd.io/COREDUMP_PACKAGE_METADATA/ [2] https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects [3] https://github.com/systemd/package-notes signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
