"Failed to start firewalld" after upgrade from Leap 15.4

I noticed that during the first boot up after the upgrade that firewalld failed to start. Hoping to get a meaningful error message, I attempted to start it manually:

# systemctl start firewalld.service
Job for firewalld.service failed because the control process exited with error code.
See "systemctl status firewalld.service" and "journalctl -xeu firewalld.service" for details.
# systemctl status firewalld.service
Γ— firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Tue 2023-08-22 15:24:48 EDT; 24min ago
       Docs: man:firewalld(1)
    Process: 29656 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=exited, status=1/FAILURE)
   Main PID: 29656 (code=exited, status=1/FAILURE)

Aug 22 15:24:48 linux-desktop systemd[1]: Starting firewalld - dynamic firewall daemon...
Aug 22 15:24:48 linux-desktop systemd[1]: firewalld.service: Main process exited, code=exited, status=1/FAILURE
Aug 22 15:24:48 linux-desktop systemd[1]: firewalld.service: Failed with result 'exit-code'.
Aug 22 15:24:48 linux-desktop systemd[1]: Failed to start firewalld - dynamic firewall daemon.
# journalctl -xeu firewalld.service
[snip: I tried more than once.]
Aug 22 15:49:57 linux-desktop systemd[1]: Starting firewalld - dynamic firewall daemon...
β–‘β–‘ Subject: A start job for unit firewalld.service has begun execution
β–‘β–‘ Defined-By: systemd
β–‘β–‘ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
β–‘β–‘ 
β–‘β–‘ A start job for unit firewalld.service has begun execution.
β–‘β–‘ 
β–‘β–‘ The job identifier is 3465.
Aug 22 15:49:57 linux-desktop systemd[1]: firewalld.service: Main process exited, code=exited, status=1/FAILURE
β–‘β–‘ Subject: Unit process exited
β–‘β–‘ Defined-By: systemd
β–‘β–‘ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
β–‘β–‘ 
β–‘β–‘ An ExecStart= process belonging to unit firewalld.service has exited.
β–‘β–‘ 
β–‘β–‘ The process' exit code is 'exited' and its exit status is 1.
Aug 22 15:49:57 linux-desktop systemd[1]: firewalld.service: Failed with result 'exit-code'.
β–‘β–‘ Subject: Unit failed
β–‘β–‘ Defined-By: systemd
β–‘β–‘ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
β–‘β–‘ 
β–‘β–‘ The unit firewalld.service has entered the 'failed' state with result 'exit-code'.
Aug 22 15:49:57 linux-desktop systemd[1]: Failed to start firewalld - dynamic firewall daemon.
β–‘β–‘ Subject: A start job for unit firewalld.service has failed
β–‘β–‘ Defined-By: systemd
β–‘β–‘ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
β–‘β–‘ 
β–‘β–‘ A start job for unit firewalld.service has finished with a failure.
β–‘β–‘ 
β–‘β–‘ The job identifier is 3465 and the job result is failed.

Thinking it may be a configuration issue, I attempted to run the YaST firewall config utility. A few errors popped up with all of them indicating an issue with Python3 not being able to find the β€˜gi’ module; the first one for example:

Execution of command "[["firewall-cmd", "--state"]]" failed.
Exit code: 1
Error output: Traceback (most recent call last):
  File "/usr/bin/firewall-cmd", line 24, in <module>
    from gi.repository import GObject
ModuleNotFoundError: No module named 'gi'

An attempt to run firewall-cmd from a command line confirmed the issue.

Is this the reason firewalld fails to start?

I find no gi-repository package related to Python3, but I do find these:

> zypper se girepository
Loading repository data...
Reading installed packages...

S  | Name                        | Summary                             | Type
---+-----------------------------+-------------------------------------+--------
i+ | girepository-1_0            | Base GObject Introspection Bindings | package
i+ | libgirepository-1_0-1       | GObject Introspection Library       | package
   | libgirepository-1_0-1-32bit | GObject Introspection Library       | package
> zypper if girepository-1_0 libgirepository-1_0-1
Loading repository data...
Reading installed packages...


Information for package girepository-1_0:
-----------------------------------------
Repository     : Main Repository
Name           : girepository-1_0
Version        : 1.70.0-150400.2.10
Arch           : x86_64
Vendor         : SUSE LLC <https://www.suse.com/>
Installed Size : 717.7 KiB
Installed      : Yes
Status         : up-to-date
Source package : gobject-introspection-1.70.0-150400.2.10.src
Upstream URL   : https://wiki.gnome.org/Projects/GObjectIntrospection
Summary        : Base GObject Introspection Bindings
Description    : 
    The goal of the project is to describe the APIs and collect them in
    a uniform, machine readable format.


Information for package libgirepository-1_0-1:
----------------------------------------------
Repository     : Main Repository
Name           : libgirepository-1_0-1
Version        : 1.70.0-150400.2.10
Arch           : x86_64
Vendor         : SUSE LLC <https://www.suse.com/>
Installed Size : 240.8 KiB
Installed      : Yes
Status         : up-to-date
Source package : gobject-introspection-1.70.0-150400.2.10.src
Upstream URL   : https://wiki.gnome.org/Projects/GObjectIntrospection
Summary        : GObject Introspection Library
Description    : 
    The goal of the project is to describe the APIs and collect them in
    a uniform, machine readable format.

Am I missing a package? Or … something else?

Well, I solved it.

Not knowing what havoc it might cause, I decided to try running /usr/sbin/firewalld from the command line. It failed:

# ./firewalld --nofork --nopid
Traceback (most recent call last):
  File "/usr/sbin/./firewalld", line 29, in <module>
    import dbus
ModuleNotFoundError: No module named 'dbus'

But, dbus for Python is installed:

# zypper se python3-dbus
Loading repository data...
Reading installed packages...

S  | Name                      | Summary                                                   | Type
---+---------------------------+-----------------------------------------------------------+--------
   | python3-dbus-presage      | Intelligent predictive text entry platform (dbus service) | package
i+ | python3-dbus-python       | Python bindings for D-Bus                                 | package
i  | python3-dbus-python-devel | Python bindings for D-Bus -- development files            | package

It turns out the both installed packages, β€˜python3-dbus-python’ and β€˜python3-gobject’, provide site packages for Python3.6. But, /usr/lib/python3 was linked to python3.11.

Management of the myriad version of Python 3 is a mess. Why even have Python3.11 if it can’t be used?

1 Like

Good debug!

Yes, managing different python versions is difficult.

My guess on why things might be buggered up is that you once installed a python3.11 module causing somehow that /usr/lib/python3 got linked to python3.11.

That would be my guess as well.

Some Python packages require a version > 3.8. Perhaps those should be installed and run within a virtual environment configured with a Python that satisfies that requirement. I can’t think of any other way to make the difference version requirements co-exist.