On 4/22/19 12:25 PM, Adam Williamson wrote:
On Sat, 2019-04-20 at 07:59 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Apr 19, 2019 at 04:35:54PM -0400, John Florian wrote:
I'm generally familiar with how systemd presets work but I'm at a
bit of loss as to how part of all the magic works. To best explain
my confusion, let me say that I make a customized live spin of
Fedora and I have a package we'll call "my-dist" which is similar in
nature to the "fedora-release" package in that it provides a custom
preset file. I still use fedora-release because this spin is not
*that* customized, so it's best to think of this as an extension. I
have another package we'll call "my-service" which has a systemd
service unit file and all the usual %systemd_post, etc. macros.
When I boot my live spin I find that my-service is not enabled
despite the preset in my-dist. I can "systemctl preset-all" to
rectify this so I believe most requirements are correct. I do see
that livemedia-creator installs my-service *before* it installs
my-dist so if the %systemd_post is called as each rpm is installed
that would explain my problem because my custom preset isn't present
yet.
How does Fedora itself accomplish this??? I don't see every package
providing a service having a dependency on fedora-release to address
this ordering issue. I can certainly stick the "systemctl
preset-all" into the %post of my kickstart as final cleanup, but
that feels dirty and wrong. Similarly, I don't wish to have to have
a "Requires: my-dist" in every one of "my-service" and other
packages like it. I've scrutinized fedora-release.spec and didn't
see anything all that different than what I have in my-dist.
systemd.rpm does preset-all when it is installed, so it is enough
that systemd.rpm is installed after fedora-release-common.rpm.
fedora-release-common is required by setup.rpm, so it is installed
early. But you raise a good point — I don't see any *explicit*
ordering chain between fedora-release-common and systemd.
There is no need to order individual rpms against either
fedora-release-common and other packages providing presets or
systemd. The only thing that is necessary is for systemd.rpm to be
installed after all presets. If that is satisfied, packages proving
services can be installed both earlier and later and the effect
(in the sense of service enablement) should be identical.
AIUI, the design is that any package that *ships a preset* should run
systemctl preset on it in its scriptlets (there should be guidelines
for this somewhere but I can't find them right now). However, there's a
loophole here in that if any package that ships a preset gets ordered
before systemd itself during install, its attempt to run 'systemctl
preset' will obviously fail. This is why we run 'preset-all' in the
systemd package scriptlets: to apply the presets for any packages which
were already installed. It's not intended that all other packages can
*rely* on the call in systemd's scripts.
So, basically: if you're making a package that includes presets, run
'systemctl preset' on the presets it ships in its scripts. Not 'preset-
all', but run it specifically per preset that you ship.
Ahha! That was worded perfectly for me to recognize where I erred. All
the other comments were doing great things for my understanding, but
this put the spotlight just right. I have numerous services I use to
transform Fedora into a stateless appliance OS, but I went too far in
mimic what I saw from Fedora itself. Each of my packages that provides
a service do indeed use the wonderful systemd scriptlets, but all of my
presets ship in separate package ("my-dist" from above) that kind of
mimics fedora-release (and its
/usr/lib/systemd/system-preset/90-default.preset file). This my-dist
package doesn't use the scriptlets at all since I didn't see that in
fedora-release.spec. I went this route because I wanted to capture the
policy of each of my custom services all in one place, much like the
aforementioned file does for Fedora.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
