Firewall does not start after system upgrade to F39

I noticed firewall does not start after a workstation’s system upgrade to Fedora 39.
Status check returns this message:

systemctl status firewalld

× firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: timeout) since Wed 2023-11-08 15:18:09 CET; 9min ago
       Docs: man:firewalld(1)
    Process: 1499 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=killed, signal=TERM)
   Main PID: 1499 (code=killed, signal=TERM)
        CPU: 522ms

Nov 08 15:17:24 workstation systemd[1]: Starting firewalld.service - firewalld - dynamic firewall daemon...
**Nov 08 15:18:09 workstation systemd[1]: firewalld.service: start operation timed out. Terminating.**
**Nov 08 15:18:09 workstation systemd[1]: firewalld.service: Failed with result 'timeout'.**
**Nov 08 15:18:09 workstation systemd[1]: Failed to start firewalld.service - firewalld - dynamic firewall daemon.**

Firewall gets started if I launch it manually with “systemctl start firewalld”.
I also tried enable, but it did not get started on the next reboot.

Can you post the output of journalctl -u firewalld -b 0 before you fix it.

FYI all systemctl enable does is add a systemd service to the default target, firewalld was already being started. Which is why it makes no difference.

I rebooted once more, and this time it seems to be working fine. I’ll keep an eye on it after every reboot to ensure it remains reliable. The journalctl output appears okay:
“Started firewalld.service - firewalld - dynamic firewall daemon.”
Thank you for your response, even though the issue seems to be resolved for now.

You may have a race condition in your systemd services.
Maybe its sensitive to the time it takes to bring up some of the interfaces on your machine.

I wonder if it was a good idea to perform a system upgrade instead of a clean install. I will keep an eye on it and we’ll see. Indeed the booting process take quite long.

I upgrade my house router that is Fedora based from version to version without concern.

There is nothing that a clean install will help with that an upgrade will not do as well.
Its only the move from ext4 to btrfs that makes fresh install on a desktop/laptop worth doing.

For my critical systems I first boot them from a USB SSD that has the new fedora version installed on it.

That way I can check for hardware support issues, its been rare to see issues.

journalctl looks like this when the firewall fails to load:

journalctl -u firewalld -b 0
Nov 09 10:31:44 workstation systemd[1]: Starting firewalld.service - firewalld - dynamic firewall daemon…
Nov 09 10:32:29 workstation systemd[1]: firewalld.service: start operation timed out. Terminating.
Nov 09 10:32:29 workstation systemd[1]: firewalld.service: Failed with result ‘timeout’.
Nov 09 10:32:29 workstation systemd[1]: Failed to start firewalld.service - firewalld - dynamic firewall daemon.

Are there any clues in the journal logs leading up to the timeout?
You may need to compare the logs when things work vs. when they fail.

I have limited experience fixing firewalld (it has mostly just worked for me) but found this that may help find out what is happening Documentation - HowTo - Debug firewalld | firewalld

Can confirm this happens with F38 too.
It is not consistent and sometimes the firewalld starts.
But as a workaround I keep my network interfaces in manual connect mode.

I see it is started with python3.
I believe I’m on python 3.11, 3.9 and 3.8 or 3.7.
Can you really mess with a python “install”… maybe if I forget to activate an venv, and do pip install?

BTW, where’s the solution here? The marked solution is only a troubleshooting direction.

If you installed or upgraded to F39 then you probably have python 3.12 installed and operating. There was a significant change between python 3.11 and 3.12 so some python using apps may no longer function properly. You can tell which version is installed with python --version

Note that the thread already had a solution posted, so it is best that you open a new thread for your own problems. It will then get the attention it deserves.