The only reason why systemd is there is DNF. It has %{?systemd_requires}, but it has only dnf-makecache.{timer,service} so I think we can drop it.

Though, @ngompa pointed out that dnf-data ships %{_tmpfilesdir}/dnf.conf but does not call any scriptlet for that.

@ignatenkobrain Hmm, I thought we did call a script for it... In any case, these days, it'd be invoked via file trigger.

The problem is that DNF behaves very poorly when the directories don't exist in the container...

What kind of container? There are containers which definitely require an init process, to start services. Then there are containers which still require something to reap zombies. So before we go ripping out stuff, let's clarify what we are ripping it out of ;)

What kind of container? There are containers which definitely require an init process, to start services. Then there are containers which still require something to reap zombies. So before we go ripping out stuff, let's clarify what we are ripping it out of ;)

Yes I think this is a valid point, I guess we could follow what UBI does and provide 3 base images.

fedora
fedora-minimal
fedora-init

We currently have fedora and fedora-minimal but we don't have the fedora-init. So if we were to drop systemd from the fedora and fedora-minimal images I think we need to introduce the fedora-init image first.

What kind of container? There are containers which definitely require an init process, to start services. Then there are containers which still require something to reap zombies. So before we go ripping out stuff, let's clarify what we are ripping it out of ;)

@zbyszek's comment is exactly why I don't want to focus on containers [1] and decide what goes there and what doesn't. I's a very different discussion.

If there are some use cases of container images not having systemd (and yes there are), we can definitely enable them by making possible for the packages to be installed functional without systemd, but leave the actual decision of removing vs. keeping it there (or having two variants of images) for the image maintainers.

[1] The "Images are not our direct goal" part of https://docs.fedoraproject.org/en-US/minimization/#_strategy

Independent of the wider discussion (what is a "container", etc.), it's totally reasonable to drop %systemd_requires from dnf rpm. Guidelines change: https://pagure.io/packaging-committee/pull-request/890.

@ignatenkobrain I wonder if the change in dnf is causing the following error

If nothing else is pulling systemd in, that would be plausible.

Ha I think I found why, in the post install section in the kickstart we are using systemctl to disable or mask some services

https://pagure.io/fedora-kickstarts/blob/master/f/fedora-container-base.ks#_30

I guess we don't need that anymore :smile:

Ok so after looking at it a bit closer, I think anaconda is expecting systemd to be present. It is trying to configure the systemd default target during the installation.

I did not see a way to bypass that but I am far from being an expert in anaconda. I ll wait and see if the anaconda folks respond to my question on their IRC channel.

For background, this came up during our previous minimization efforts:

https://pagure.io/packaging-committee/issue/644

The difference can be seen here comparing f30 (with systemd), and f31 or Rawhide (without) https://minimization.github.io/reports/report-base-releases--fedora-container-base.html

The difference can be seen here comparing f30 (with systemd), and f31 or Rawhide (without) https://minimization.github.io/reports/report-base-releases--fedora-container-base.html

I just want to point out that the reason for this change is due to dnf dropping it's dependency on systemd. As was talked about in this comment https://pagure.io/minimization/issue/2#comment-587776

I have created pull requests to remove systemd from httpd and nginx.

httpd: https://src.fedoraproject.org/rpms/httpd/pull-request/7
nginx: https://src.fedoraproject.org/rpms/nginx/pull-request/5

Note, that when you remove systemd from container then you cannot create users and groups using sysusers.

Note, that when you remove systemd from container then you cannot create users and groups using sysusers.
Thank you for bringing this up. You are correct, and this is going to need a bigger discussion. I have created a new issue just for this.

https://pagure.io/minimization/issue/13

systemd is still in the main Fedora containers. The culprit is gnupg2 (possibly)

gpgme and rpm-sign-libs -> gnupg2 -> libusbx -> systemd-libs

Other things are pulled in with libusbx, most of them hardware related.

systemd is still in the main Fedora containers. The culprit is gnupg2 (possibly)
gpgme and rpm-sign-libs -> gnupg2 -> libusbx -> systemd-libs
Other things are pulled in with libusbx, most of them hardware related.

Sveral things came out of investigating this.

• gnupg2 either has usb enabled through all the software, or not at all. There isn't some binary or library that we can put in a sub-package. Looking at the use cases for gnupg2 and usb, I agree with the packagers that usb should remain on.
• systemd-libs does not pull in the rest of systemd, or any other dependencies. So, while libusbx and systemd-libs are hardware packages, they are not that huge. It is not worth the effort to pull them out.
• systemd is put into the container due to an anaconda bug. anaconda is used to create the initial fedora image. https://github.com/rhinstaller/anaconda/pull/2098 The pull request to fix the bug has been merged and built (anaconda-32.3). Now it's just a matter of time before this get's put on the koji builders, and systemd can be removed from the base fedora container.

Once the koji builder are updated to Fedora 31, we should be able to use the version of anaconda that has the fix in it.

I think that this should happen soon :smile:

Have the koji builders been updated to Fedora 31?
And if so, have we been able to remove systemd from base containers and images?

Install of httpd on Fedora-Container-Minimal-Base image is not successfull due to systemd. see https://bugzilla.redhat.com/show_bug.cgi?id=1824208

Install of httpd on Fedora-Container-Minimal-Base image is not successfull due to systemd. see https://bugzilla.redhat.com/show_bug.cgi?id=1824208

Although this deals with minimizing, this needs to stay with the container images team, not the minimization team.
I have put my investigation information in the bugzilla.

But, for those that are seeing just this, when trimming down unnecessary files out of rpms, they accidentally took out the libsystemd-shared-245.so file, which is needed by systemctl.

I am not sure that there is a container images team :P

For info systemd has now been remove from both base image (fedora and fedora-minimal) in rawhide.

It would be nice to have people testing it to see if everything is working as expected :)

cc @siddharthvipul1

I am not sure that there is a container images team :P
For info systemd has now been remove from both base image (fedora and fedora-minimal) in rawhide.
It would be nice to have people testing it to see if everything is working as expected :)
cc @siddharthvipul1
Yes, I confirm is working fine still Fedora-Container-Minimal-Base-30-20200525.0.ppc64le.tar.xz
Thanks

Yes, I confirm is working fine still Fedora-Container-Minimal-Base-30-20200525.0.ppc64le.tar.xz
Thanks

We have removed systemd just from the rawhide. Please test that :)
Thank you

here is a link to the build https://koji.fedoraproject.org/koji/buildinfo?buildID=1514234

argh, I looked to wrong tests, tests are running automatically in my openqa environment on available nightly composes.

Fedora-Container-Minimal-Base-30-20200525.0.ppc64le.tar.xz don't have the problem (I guess he never had).

Fedora-Container-Minimal-Base-31-20200525.0.ppc64le.tar.xz and
Fedora-Container-Minimal-Base-32-20200526.0.ppc64le.tar.xz still failed with: error while loading shared libraries: libsystemd-shared-245.so at hhttpd installation

and Fedora-Container-Minimal-Base-Rawhide-20200525.n.0.ppc64le.tar.xz don't have the problem on httpd install anymore.

Please confirm me your change is already in https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200525.n.0/compose/Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200525.n.0.ppc64le.tar.xz

Please confirm me your change is already in https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200525.n.0/compose/Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200525.n.0.ppc64le.tar.xz

Yes! every rawhide nightly build after https://www.pagure.io/fedora-kickstarts/pull-request/645 getting merged should be without systemd

I don't see any side effect right now so this change can be applied on f31 and f32.

I don't see any side effect right now so this change can be applied on f31 and f32.

done :)
Thank you for testing rawhide build, I will ping some more folks to confirm it working in these as well

I have proposed reverting this change for stable releases at https://pagure.io/fedora-kickstarts/pull-request/660

I think it would be good to have a solution for https://bugzilla.redhat.com/show_bug.cgi?id=1841139 before Fedora 33 is released. I saw a suggestion upthread to provide a fedora-init base image that still contains systemd, which I think would probably be acceptable (perhaps naming it fedora-systemd would aid users in discovering it?). I think it might be ideal to get the systemd units to a state where they somehow avoid failing when running in containers, though I'm not sure if that is feasible or not.

In any case, if we proceed as-is, I think this may be painful for users who are using systemd in containers since they need to do more than a simple dnf install systemd to have a working container.

What a nightmare
When the systemctl command doesn't exist in fedora 32
and just found out the systemd package was removed.
Will there be a fedora-init like @cverna said?

Hi everyone,

As @cverna and @vasintalana have mentioned, not having a fedora-init image is making things harder for those of us that need one.

My use case: I’m a web developer and I use Fedora Silverblue. One of the things I make is a web server that I need to test from within a container.

Distrobox enables me to create a rootful container with an init system – which is what I need as a developer – but it needs an image that has systemd in it.

Please see this issue for more details.

Thanks for your time.