[systemd-devel] making firewalld an early boot service

[Andrei Borzenkov]

On Wed, Mar 9, 2022 at 10:18 AM Michael Biebl <mbiebl at gmail.com> wrote:
>
> Am Mi., 9. März 2022 um 06:49 Uhr schrieb Andrei Borzenkov
> <arvidjaar at gmail.com>:
> >
> > On 09.03.2022 00:59, Michael Biebl wrote:
> > > Hi,
> > >
> > > I need help with firewalld issue, specifically
> > > https://github.com/firewalld/firewalld/issues/414
> > >
> > > the TLDR: both firewalld.service and cloud-init-local.service hook
> > > into network-pre.target and have a Before=network-pre.target ordering.
> > >
> > > cloud-init-local.service is an early boot service using
> > > DefaultDependencies=no and before sysinit.target.
> > > firewalld.service via DefaultDependencies=yes get's an
> > > After=sysinit.target ordering.
> > >
> > > So we have conflicting requirements and a dependency loop that needs
> > > to be broken by systemd.
> > >
> >
> > Firewalld is red herring here. cloud-init.service has
> >
> > After=networking.service
> > Before=sysinit.target
> >
> > This is a loop which has nothing to do with firewalld.
>
> Afaics firewalld.service is involved here.
> For one, without it installed, there is no such ordering cycle.
>

OK, seems networking.service has DefaultDepencies=no, so yes, without
firewalld it can be moved early.

> To me it looks like cloud-init.service and firewalld.service are tied
> together via this cloud-init-local.service
>

The loop below (from the firewalld issue) does not involve
cloud-init-local.service.

>
> > [    1.643638] systemd[1]: sysinit.target: Found ordering cycle on
> > cloud-init.service/start
> > [    1.645482] systemd[1]: sysinit.target: Found dependency on
> > networking.service/start
> > [    1.647274] systemd[1]: sysinit.target: Found dependency on
> > network-pre.target/start
> > [    1.649010] systemd[1]: sysinit.target: Found dependency on
> > firewalld.service/start
> > [    1.650718] systemd[1]: sysinit.target: Found dependency on
> > dbus.service/start
> > [    1.652294] systemd[1]: sysinit.target: Found dependency on
> > basic.target/start
> > [    1.654033] systemd[1]: sysinit.target: Found dependency on
> > sysinit.target/start
> > [    1.655528] systemd[1]: sysinit.target: Job cloud-init.service/start
> > deleted to break ordering cycle starting with sysinit.target/start
> >
> >
> > ...
> >
> > >
> > >
> > > I dropped the After=dbus.service polkit.service orderings, as they are
> > > either socket or D-Bus activated services, added an explicit
> > > After=local-fs.target ordering just to be sure and hooked it into
> > > sysinit.target.
> > >
> > > Would you agree that making a firewall service an early boot service
> > > is a good idea?
> >
> > Firewalld cannot be socket activated. The whole reason to have firewall
> > (any firewall) startup service is to instantiate netfilter configuration
> > before networking becomes available. When exactly it is done does not
> > matter - it can well be done as early boot service. But it cannot be
> > delayed until something contacts firewall endpoint. It must be done
> > before network-pre.target.
>
> I don't think i said I want firewalld to become socket activated?
> What I did was drop After=dbus.service and After=polkit.service.
> firewald.service is a Type=dbus service, so already get's an explicit
> After=dbus.socket, Requires=dbus.socket which I think should satisfy
> firewalld's D-Bus requirements, no?
>
> > > Does the above make sense or have I missed something?
> > >
> > > Feedback welcome.
> >
> > firewalld requires D-Bus so it must be started after D-Bus. You cannot
> > start it earlier.
>
> See above, being Type=dbus, it has an explicit Requires/After=dbus.socket.

I do not see how it helps. Firewalld cannot become active before D-Bus
is started. If firewalld.service is ordered before network-pre.target
systemd will wait for firewalld.service to become ready before
activating network-pre.target. If network-pre.target is ordered before
sysinit.target and hence before D-Bus service it means deadlock.

It may work with systemd-networkd which dropped DefaultDependencies
and so could be arbitrarily shuffled in boot sequence, but
network.service is a generic alias that normally points to the actual
implementation. Can you start NetworkManager before sysinit.target?