Bug 1497759

Thank you, Petr. The patch needs some cleanup, but the functionality looks good to me...

We were already facing a problem with ifup/ifdown being too slow when calling 'nmcli' directly, and we switched to using D-Bus calls instead. So I'm okay if we fix this the same way to speed things up.

However, I will have to discuss with Lukas why we had the calls to firewall-cmd 2-times. There might have been reason for it, and we don't want to break anything.

Another thing - I might be wrong, but just from top of my head - was there not a plan to replace D-Bus in the future with something else?

Lastly - I see Dan is proposing a RHEL-7.4.z fix. Is there any specific case where this is causing big problems?

(In reply to David Kaspar [Dee'Kej] from comment #2)
> 
> Lastly - I see Dan is proposing a RHEL-7.4.z fix. Is there any specific case
> where this is causing big problems?

RHV receives multiple customers requesting to attach multiple (tens, hundreds) of networks to a host in one RHV command. RHV's commands timeout after 2 minutes, which limits the number of networks (each with a bridge and a vlan) we can attach. But let us first fix it in 7.5. Only if the fix is as simple as Petr suggests, shall we consider the implications of a backport.

(In reply to Dan Kenigsberg from comment #3)
> (In reply to David Kaspar [Dee'Kej] from comment #2)
> > 
> > Lastly - I see Dan is proposing a RHEL-7.4.z fix. Is there any specific case
> > where this is causing big problems?
> 
> RHV receives multiple customers requesting to attach multiple (tens,
> hundreds) of networks to a host in one RHV command. RHV's commands timeout
> after 2 minutes, which limits the number of networks (each with a bridge and
> a vlan) we can attach. But let us first fix it in 7.5. Only if the fix is as
> simple as Petr suggests, shall we consider the implications of a backport.

Oh, I see. That makes IMHO a good validation for 7.5 and 7.4.z.

Adding needinfo on our colleagues for them to provide necessary ACKs if they agree.

After discussion with Lukas, we would like to first know why is the firewalld slow in the first place, and could we fix it there?

(In reply to David Kaspar [Dee'Kej] from comment #5)
> After discussion with Lukas, we would like to first know why is the
> firewalld slow in the first place, and could we fix it there?

Short answer: No.

Python is an interpreted language. When the program start it has to go through the python interpreter. There is not much you can do to improve the startup time.

Python does automatically compile the library code to byte code, which helps some. This can also be done for the firewall-cmd executable, but my tests show it only brings a 10-20ms (0.255s --> 0.226s) improvement for "firewall-cmd --list-all".

(In reply to Eric Garver from comment #6)
> Python is an interpreted language. When the program start it has to go
> through the python interpreter. There is not much you can do to improve the
> startup time.
> 
> Python does automatically compile the library code to byte code, which helps
> some. This can also be done for the firewall-cmd executable, but my tests
> show it only brings a 10-20ms (0.255s --> 0.226s) improvement for
> "firewall-cmd --list-all".

Thank you for clarification, Eric. I have one more favor to ask you - could you please look at the patches suggested by Petr, and confirm that these D-Bus calls are equivalent to the original firewalld-cmd calls?

Thank you!

(In reply to David Kaspar [Dee'Kej] from comment #7)
> (In reply to Eric Garver from comment #6)
> > Python is an interpreted language. When the program start it has to go
> > through the python interpreter. There is not much you can do to improve the
> > startup time.
> > 
> > Python does automatically compile the library code to byte code, which helps
> > some. This can also be done for the firewall-cmd executable, but my tests
> > show it only brings a 10-20ms (0.255s --> 0.226s) improvement for
> > "firewall-cmd --list-all".
> 
> Thank you for clarification, Eric. I have one more favor to ask you - could
> you please look at the patches suggested by Petr, and confirm that these
> D-Bus calls are equivalent to the original firewalld-cmd calls?
> 
> Thank you!

They are not correct. The removeInterface command is missing the zone argument.

If you care about the return code you should add the --print-reply and redirect stdout to /dev/null. This will make dbus-send block and return an appropriate error code. As it is now, the dbus-send is fire and forget - which also explains why it's so much faster than firewall-cmd.

Correct versions:

  dbus-send --print-reply --system --dest=org.fedoraproject.FirewallD1 \
            /org/fedoraproject/FirewallD1 \
            org.fedoraproject.FirewallD1.zone.changeZoneOfInterface \
            string:"${ZONE}" string:"${DEVICE}" \
            > /dev/null
  # do something with $?

Note: An empty string in first argument implies "default" zone, but it must have both arguments.

  dbus-send --print-reply --system --dest=org.fedoraproject.FirewallD1 \
            /org/fedoraproject/FirewallD1 \
            org.fedoraproject.FirewallD1.zone.removeInterface \
            string: "" string:"${DEVICE}" \
            > /dev/null
  # do something with $?

Pull-request submitted for review:
https://github.com/fedora-sysv/initscripts/pull/132

Based on the follow-up discussion in the pull-request, I have updated the DBus call in ifup-eth script to be *synchronous* (for IPv6 DHCP setups). The rest of the calls remains asynchronous, for maximal speed increase.

 -- David --

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0983