Description of problem: Pretty much as it says, upgrading libvirt (since at least 5.10) kills networking. It's unclear exactly what it breaks, but existing SSH connections survive, but no new connections to the machine (of any kind) are possible. Version-Release number of selected component (if applicable): 5.10 -> 6.0.0, and 6.0.0 -> 6.1.0 both have this problem. How reproducible: 100% Steps to Reproduce: 1. dnf update libvirt-daemon
Created attachment 1667700 [details] journalctl --since "today" Journal since today. The update happened about 10:23:51 in this log.
I notice from the logs that firewalld segfaulted during the upgrade, which seems like it could be relevant here. The stack trace is very long and mostly consists of Python frames, so not that useful.
Although firewalld was dead, it was possible to restart it. However that did not fix the network. Here is the rest of the network configuration (after being broken): 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 04:d9:f5:1f:9e:9e brd ff:ff:ff:ff:ff:ff inet 192.168.0.139/24 brd 192.168.0.255 scope global dynamic noprefixroute enp5s0 valid_lft 1440sec preferred_lft 1440sec inet6 2001:8b0:9ad:8728:4e3:47dc:6088:a4da/64 scope global dynamic noprefixroute valid_lft 85716sec preferred_lft 13716sec inet6 fe80::6402:af78:7c89:95e9/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:9e:38:14 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:9e:38:14 brd ff:ff:ff:ff:ff:ff Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 enp5s0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp5s0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
default via 192.168.0.1 dev enp5s0 proto dhcp metric 20100 192.168.0.0/24 dev enp5s0 proto kernel scope link src 192.168.0.139 metric 100 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown # Generated by iptables-save v1.8.4 on Thu Mar 5 10:39:02 2020 *nat :PREROUTING ACCEPT [144:11736] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [9:648] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Thu Mar 5 10:39:02 2020 # Generated by iptables-save v1.8.4 on Thu Mar 5 10:39:02 2020 *mangle :PREROUTING ACCEPT [600:47320] :INPUT ACCEPT [600:47320] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [338:236036] :POSTROUTING ACCEPT [329:235388] COMMIT # Completed on Thu Mar 5 10:39:02 2020 # Generated by iptables-save v1.8.4 on Thu Mar 5 10:39:02 2020 *raw :PREROUTING ACCEPT [600:47320] :OUTPUT ACCEPT [338:236036] COMMIT # Completed on Thu Mar 5 10:39:02 2020 # Generated by iptables-save v1.8.4 on Thu Mar 5 10:39:02 2020 *security :INPUT ACCEPT [456:35584] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [329:235388] COMMIT # Completed on Thu Mar 5 10:39:02 2020 # Generated by iptables-save v1.8.4 on Thu Mar 5 10:39:02 2020 *filter :INPUT ACCEPT [600:47320] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [338:236036] COMMIT # Completed on Thu Mar 5 10:39:02 2020
Created attachment 1667709 [details] nft list ruleset
Created attachment 1667712 [details] nft list ruleset after rebot If you diff the broken nft ruleset and this working nft ruleset you can see large differences. It appears that in the broken ruleset, firewalld added rules twice. The diff is very large, but an example hunk is: chain nat_PREROUTING { type nat hook prerouting priority dstnat + 10; policy accept; jump nat_PREROUTING_ZONES - jump nat_PREROUTING_ZONES } Unclear to me if adding all the rules twice would result in a broken firewall or merely the firewall doing extra work.
The other difference is that the inauspiciously named ‘table inet firewalld_policy_drop’ appears in the broken ruleset but not in the working ruleset.
It is hard to say without understanding NFT better than I can, but this does suggest that the firewalld crash is the most likely cause of the problem. In the %post script of daemon-driver-network we request a "firewall-cmd --reload " to pick up libvirt's firewalld zone. I assume a bug in firewalld caused it to crash when doing this reload and the result broke your network.
Looking at the firewalld code here: https://github.com/firewalld/firewalld/blob/81d784f8c856704d85319d634318aae2c9f5ad23/src/firewall/core/nftables.py#L431 it seems a plausible explanation is that firewalld added table inet firewalld_policy_drop temporarily while reloading the rules, but firewalld then segfaulted during the upgrade, and that table was left around even after firewalld was later successfully reloaded.
Core was generated by `/usr/bin/python3 /usr/sbin/firewalld --nofork --nopid'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. (gdb) t a a bt Thread 3 (Thread 0x7f8a2eddb700 (LWP 2481)): #0 0x00007f8a3f5bf95f in poll () at /lib64/libc.so.6 #1 0x00007f8a308a6a9e in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0 #2 0x00007f8a308a6bd3 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #3 0x00007f8a308a6c21 in glib_worker_main () at /lib64/libglib-2.0.so.0 #4 0x00007f8a308d0752 in g_thread_proxy () at /lib64/libglib-2.0.so.0 #5 0x00007f8a3f0f4462 in start_thread () at /lib64/libpthread.so.0 #6 0x00007f8a3f5caab3 in clone () at /lib64/libc.so.6 Thread 2 (Thread 0x7f8a3ef95740 (LWP 2211)): #0 0x00007f8a3f5bf95f in poll () at /lib64/libc.so.6 #1 0x00007f8a308a6a9e in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0 #2 0x00007f8a308a6e23 in g_main_loop_run () at /lib64/libglib-2.0.so.0 #3 0x00007f8a316530e6 in init_sync () at /lib64/libnm.so.0 #4 0x00007f8a305d70ba in g_initable_new_valist () at /lib64/libgio-2.0.so.0 #5 0x00007f8a305d716d in g_initable_new () at /lib64/libgio-2.0.so.0 #6 0x00007f8a307bcaa8 in ffi_call_unix64 () at ../src/x86/unix64.S:76 #7 0x00007f8a307bc2a4 in ffi_call (cif=<optimized out>, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>) at ../src/x86/ffi64.c:525 #8 0x00007f8a309d4060 in pygi_invoke_c_callable () at /usr/lib64/python3.8/site-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so #9 0x00007f8a309d5be8 in _constructor_cache_invoke_real () at /usr/lib64/python3.8/site-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so #10 0x00007f8a309d5d6c in pygi_function_cache_invoke () at /usr/lib64/python3.8/site-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so #11 0x00007f8a309c64be in _callable_info_call () at /usr/lib64/python3.8/site-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so #12 0x00007f8a3f247432 in _PyObject_MakeTpCall () at /lib64/libpython3.8.so.1.0 #13 0x00007f8a3f2ff23e in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #14 0x00007f8a3f2ebd8d in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #15 0x00007f8a3f2f9e79 in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #16 0x00007f8a3f2ebd8d in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #17 0x00007f8a3f2f9e79 in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #18 0x00007f8a3f2ebd8d in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #19 0x00007f8a3f2f9e79 in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #20 0x00007f8a3f2eac1b in _PyEval_EvalCodeWithName () at /lib64/libpython3.8.so.1.0 #21 0x00007f8a3f2ebf6b in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #22 0x00007f8a3f2fa311 in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 --Type <RET> for more, q to quit, c to continue without paging--c #23 0x00007f8a3f2eac1b in _PyEval_EvalCodeWithName () at /lib64/libpython3.8.so.1.0 #24 0x00007f8a3f2ebf6b in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #25 0x00007f8a3f2462c0 in PyObject_Call () at /lib64/libpython3.8.so.1.0 #26 0x00007f8a3f2fbf2f in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #27 0x00007f8a3f2eac1b in _PyEval_EvalCodeWithName () at /lib64/libpython3.8.so.1.0 #28 0x00007f8a3f2ebf6b in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #29 0x00007f8a3f2f9e79 in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #30 0x00007f8a3f2eac1b in _PyEval_EvalCodeWithName () at /lib64/libpython3.8.so.1.0 #31 0x00007f8a3f2ebf6b in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #32 0x00007f8a3f24620a in PyObject_Call () at /lib64/libpython3.8.so.1.0 #33 0x00007f8a3f2fbf2f in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #34 0x00007f8a3f2eac1b in _PyEval_EvalCodeWithName () at /lib64/libpython3.8.so.1.0 #35 0x00007f8a3f2ebf6b in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #36 0x00007f8a3f2f9e79 in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #37 0x00007f8a3f2eac1b in _PyEval_EvalCodeWithName () at /lib64/libpython3.8.so.1.0 #38 0x00007f8a3f2ebf6b in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #39 0x00007f8a3f2462c0 in PyObject_Call () at /lib64/libpython3.8.so.1.0 #40 0x00007f8a3f2fbf2f in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #41 0x00007f8a3f2eac1b in _PyEval_EvalCodeWithName () at /lib64/libpython3.8.so.1.0 #42 0x00007f8a3f2ebf6b in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #43 0x00007f8a3f2478b0 in object_vacall () at /lib64/libpython3.8.so.1.0 #44 0x00007f8a3f247c01 in PyObject_CallFunctionObjArgs () at /lib64/libpython3.8.so.1.0 #45 0x00007f8a30ffb6d8 in _pending_call_notify_function () at /usr/lib64/python3.8/site-packages/_dbus_bindings.so #46 0x00007f8a30fa7a3b in complete_pending_call_and_unlock () at /lib64/libdbus-1.so.3 #47 0x00007f8a30fab4dd in dbus_connection_dispatch () at /lib64/libdbus-1.so.3 #48 0x00007f8a303b9f39 in message_queue_dispatch () at /usr/lib64/python3.8/site-packages/_dbus_glib_bindings.so #49 0x00007f8a308a677f in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #50 0x00007f8a308a6b08 in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0 #51 0x00007f8a308a6e23 in g_main_loop_run () at /lib64/libglib-2.0.so.0 #52 0x00007f8a307bcaa8 in ffi_call_unix64 () at ../src/x86/unix64.S:76 #53 0x00007f8a307bc2a4 in ffi_call (cif=<optimized out>, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>) at ../src/x86/ffi64.c:525 #54 0x00007f8a309d4060 in pygi_invoke_c_callable () at /usr/lib64/python3.8/site-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so #55 0x00007f8a309d5d6c in pygi_function_cache_invoke () at /usr/lib64/python3.8/site-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so #56 0x00007f8a309c64be in _callable_info_call () at /usr/lib64/python3.8/site-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so #57 0x00007f8a3f247432 in _PyObject_MakeTpCall () at /lib64/libpython3.8.so.1.0 #58 0x00007f8a3f2ff23e in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #59 0x00007f8a3f2eac1b in _PyEval_EvalCodeWithName () at /lib64/libpython3.8.so.1.0 #60 0x00007f8a3f2ebf6b in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #61 0x00007f8a3f2fa311 in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #62 0x00007f8a3f2eac1b in _PyEval_EvalCodeWithName () at /lib64/libpython3.8.so.1.0 #63 0x00007f8a3f2ebf6b in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #64 0x00007f8a3f2fed83 in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #65 0x00007f8a3f2ebd8d in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #66 0x00007f8a3f2f9e79 in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #67 0x00007f8a3f2ebd8d in _PyFunction_Vectorcall () at /lib64/libpython3.8.so.1.0 #68 0x00007f8a3f2f9e79 in _PyEval_EvalFrameDefault () at /lib64/libpython3.8.so.1.0 #69 0x00007f8a3f2eac1b in _PyEval_EvalCodeWithName () at /lib64/libpython3.8.so.1.0 #70 0x00007f8a3f370883 in PyEval_EvalCode () at /lib64/libpython3.8.so.1.0 #71 0x00007f8a3f3708d8 in run_eval_code_obj () at /lib64/libpython3.8.so.1.0 #72 0x00007f8a3f3749f3 in run_mod () at /lib64/libpython3.8.so.1.0 #73 0x00007f8a3f214e7e in PyRun_FileExFlags () at /lib64/libpython3.8.so.1.0 #74 0x00007f8a3f21f053 in PyRun_SimpleFileExFlags () at /lib64/libpython3.8.so.1.0 #75 0x00007f8a3f21fb84 in Py_RunMain.cold () at /lib64/libpython3.8.so.1.0 #76 0x00007f8a3f37fe99 in Py_BytesMain () at /lib64/libpython3.8.so.1.0 #77 0x00007f8a3f4f0052 in __libc_start_main () at /lib64/libc.so.6 #78 0x000055d049c1008e in _start () Thread 1 (Thread 0x7f8a2e56b700 (LWP 2180275)): #0 0x00007f8a308ad917 in g_log_structured_array () at /lib64/libglib-2.0.so.0 #1 0x00007f8a308add29 in g_log_default_handler () at /lib64/libglib-2.0.so.0 #2 0x00007f8a308adf79 in g_logv () at /lib64/libglib-2.0.so.0 #3 0x00007f8a308ae213 in g_log () at /lib64/libglib-2.0.so.0 #4 0x00007f8a308f458b in linux_pthread_proxy () at /lib64/libglib-2.0.so.0 #5 0x00007f8a3f0f4462 in start_thread () at /lib64/libpthread.so.0 #6 0x00007f8a3f5caab3 in clone () at /lib64/libc.so.6
There are some AVC denials in the log right before the trap. Does it still occur with "setenforce 0"?
I'm unable to test breaking changes on this machine as it's my main development machine.
Just happened again when upgrading libvirt. The segfault is again in python. firewalld-0.8.0-1.fc32.noarch
PID: 7530 (firewalld) UID: 0 (root) GID: 0 (root) Signal: 5 (TRAP) Timestamp: Tue 2020-04-14 09:22:28 BST (14min ago) Command Line: /usr/bin/python3 /usr/sbin/firewalld --nofork --nopid Executable: /usr/bin/python3.8 Control Group: /system.slice/firewalld.service Unit: firewalld.service Slice: system.slice Boot ID: 933381cd2d444b7c911cf57b7f5c871e Machine ID: 6a94c027836a43c5a93d4b04b003879e Hostname: pick Storage: /var/lib/systemd/coredump/core.firewalld.0.933381cd2d444b7c911cf57b7f5c871e.7530.1586852548000000000000.lz4 Message: Process 7530 (firewalld) of user 0 dumped core. Stack trace of thread 924234: #0 0x00007f3f3f4e5917 g_log_structured_array (libglib-2.0.so.0 + 0x59917) #1 0x00007f3f3f4e5d29 g_log_default_handler (libglib-2.0.so.0 + 0x59d29) #2 0x00007f3f3f4e5f79 g_logv (libglib-2.0.so.0 + 0x59f79) #3 0x00007f3f3f4e6213 g_log (libglib-2.0.so.0 + 0x5a213) #4 0x00007f3f3f52c58b linux_pthread_proxy (libglib-2.0.so.0 + 0xa058b) #5 0x00007f3f4dd2c462 n/a (/usr/lib64/libpthread-2.31.9000.so (deleted) + 0x9462)
Also firewalld_policy_drop has reappeared (even after restarting firewalld). Perhaps firewalld could consider unconditionally removing this table after it restarts successfully, as it appears to be left over from previous failures.
A workaround when firewalld is left broken appears to be: # nft delete table inet firewalld_policy_drop # systemctl restart firewalld
Yes again, everything broken on an update, and the only solution was to delete the rogue firewalld_policy_drop. Could you think about fixing this some time?
(In reply to Richard W.M. Jones from comment #17) > Yes again, everything broken on an update, and the only solution was to > delete the rogue firewalld_policy_drop. Could you think about fixing this > some time? Were you able to try the suggestion in comment 11? There have been no other reporters of this issue, which given the steps you gave is surprising. Maybe there is something unique to your setup.
This was on a different machine from last time. The common factor is probably libvirt-daemon. As I cannot find a reliable reproducer for this issue I cannot check what happens without SELinux enabled.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
I have the same issue with firewalld core dump sometime after it does ipset upnp in Fedora 32 with latest updates (0.8.3) since I enable upnp-client in the firewall, although disabling it doesn't help either. I tested with F34 firewalld 0.9.0 and F32 previous firewalld 0.8.2 mock built for F32, but the same problem. I tried kernels 5.7.15, 5.7.16, 5.7.17, 5.8.6, doesn't matter. When using Fedora 31 firewalld 0.7.5 mock built in F32, it works without problems. I do not run libvirt.service, although I don't know whether the library is being used. And SELinux is turned off (set to permissive). Here is a sample log in /var/log/messages, and it seems to be related to nft and how python3.8 calls nft and retrieves the results. Sep 8 01:52:56 localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@0-1096-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 8 01:52:56 localhost systemd[1]: Started Process Core Dump (PID 1096/UID 0). Sep 8 01:52:56 localhost systemd[1]: firewalld.service: Main process exited, code=dumped, status=11/SEGV Sep 8 01:52:56 localhost systemd[1]: firewalld.service: Failed with result 'core-dump'. Sep 8 01:52:56 localhost audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=firewalld comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Sep 8 01:52:56 localhost systemd-coredump[1097]: Process 868 (firewalld) of user 0 dumped core.#012#012Stack trace of thread 868:#012#0 0x00007f3d459e38d4 erec_print (libnftables.so.1.0.0 + 0x428d4)#012#1 0x00007f3d459e3d32 erec_print_list (libnftables.so.1.0.0 + 0x42d32)#012#2 0x00007f3d459e997c nft_run_cmd_from_buffer (libnftables.so.1.0.0 + 0x4897c)#012#3 0x00007f3d470c8af0 ffi_call_unix64 (libffi.so.6 + 0x6af0)#012#4 0x00007f3d470c82ab ffi_call (libffi.so.6 + 0x62ab)#012#5 0x00007f3d46545eab _ctypes_callproc.cold (_ctypes.cpython-38-x86_64-linux-gnu.so + 0x9eab)#012#6 0x00007f3d4654f8cf PyCFuncPtr_call (_ctypes.cpython-38-x86_64-linux-gnu.so + 0x138cf)#012#7 0x00007f3d55721681 _PyObject_MakeTpCall (libpython3.8.so.1.0 + 0x110681)#012#8 0x00007f3d5571e53c _PyEval_EvalFrameDefault (libpython3.8.so.1.0 + 0x10d53c)#012#9 0x00007f3d55727177 function_code_fastcall (libpython3.8.so.1.0 + 0x116177)#012#10 0x00007f3d55719647 _PyEval_EvalFrameDefault (libpython3.8.so.1.0 + 0x108647)#012#11 0x00007f3d55727177 function_code_fastcall (libpython3.8.so.1.0 + 0x116177)#012#12 0x00007f3d55719647 _PyEval_EvalFrameDefault (libpython3.8.so.1.0 + 0x108647)#012#13 0x00007f3d55727177 function_code_fastcall (libpython3.8.so.1.0 + 0x116177)#012#14 0x00007f3d55719647 _PyEval_EvalFrameDefault (libpython3.8.so.1.0 + 0x108647)#012#15 0x00007f3d55717d54 _PyEval_EvalCodeWithName (libpython3.8.so.1.0 + 0x106d54)#012#16 0x00007f3d55726e23 _PyFunction_Vectorcall (libpython3.8.so.1.0 + 0x115e23)#012#17 0x00007f3d55719647 _PyEval_EvalFrameDefault (libpython3.8.so.1.0 + 0x108647)#012#18 0x00007f3d55727177 function_code_fastcall (libpython3.8.so.1.0 + 0x116177)#012#19 0x0000 ... all_Call (libpython3.8.so.1.0 + 0x11ea90)#012#42 0x00007f3d5571b1e9 _PyEval_EvalFrameDefault (libpython3.8.so.1.0 + 0x10a1e9)#012#43 0x00007f3d55717d54 _PyEval_EvalCodeWithName (libpython3.8.so.1.0 + 0x106d54)#012#44 0x00007f3d55726e23 _PyFunction_Vectorcall (libpython3.8.so.1.0 + 0x115e23)#012#45 0x00007f3d557210a6 _PyObject_FastCallDict (libpython3.8.so.1.0 + 0x1100a6)#012#46 0x00007f3d5572d111 slot_tp_init (libpython3.8.so.1.0 + 0x11c111)#012#47 0x00007f3d5572195b type_call (libpython3.8.so.1.0 + 0x11095b)#012#48 0x00007f3d55721681 _PyObject_MakeTpCall (libpython3.8.so.1.0 + 0x110681)#012#49 0x00007f3d5571dfb1 _PyEval_EvalFrameDefault (libpython3.8.so.1.0 + 0x10cfb1)#012#50 0x00007f3d557183f4 _PyEval_EvalCodeWithName (libpython3.8.so.1.0 + 0x1073f4)#012#51 0x00007f3d55726e23 _PyFunction_Vectorcall (libpython3.8.so.1.0 + 0x115e23)#012#52 0x00007f3d5571e127 _PyEval_EvalFrameDefault (libpython3.8.so.1.0 + 0x10d127)#012#53 0x00007f3d55727177 function_code_fastcall (libpython3.8.so.1.0 + 0x116177)#012#54 0x00007f3d5571924d _PyEval_EvalFrameDefault (libpython3.8.so.1.0 + 0x10824d)#012#55 0x00007f3d55727177 function_code_fastcall (libpython3.8.so.1.0 + 0x116177)#012#56 0x00007f3d5571924d _PyEval_EvalFrameDefault (libpython3.8.so.1.0 + 0x10824d)#012#57 0x00007f3d55717d54 _PyEval_EvalCodeWithName (libpython3.8.so.1.0 + 0x106d54)#012#58 0x00007f3d55792e79 PyEval_EvalCodeEx (libpython3.8.so.1.0 + 0x181e79)#012#59 0x00007f3d55792e3b PyEval_EvalCode (libpython3.8.so.1.0 + 0x181e3b)#012#60 0x00007f3d557b4068 run_eval_code_obj (libpython3.8.so.1.0 + 0x1a3068)#012#61 0x00007f3d557b3783 run_mod (libpython3.8.so.1.0 + 0x1a2783)#012#62 0x00007f3d5569f9ce PyRun_FileExFlags (libpython3.8.so.1.0 + 0x8e9ce)#012#63 0x00007f3d5569f186 PyRun_SimpleFileExFlags (libpython3.8.so.1.0 + 0x8e186)
(In reply to Martin from comment #21) > I have the same issue with firewalld core dump sometime after it does ipset > upnp in Fedora 32 with latest updates (0.8.3) since I enable upnp-client in > the firewall, although disabling it doesn't help either. > > I tested with F34 firewalld 0.9.0 and F32 previous firewalld 0.8.2 mock > built for F32, but the same problem. I tried kernels 5.7.15, 5.7.16, 5.7.17, > 5.8.6, doesn't matter. > > When using Fedora 31 firewalld 0.7.5 mock built in F32, it works without > problems. > > I do not run libvirt.service, although I don't know whether the library is > being used. And SELinux is turned off (set to permissive). > > Here is a sample log in /var/log/messages, and it seems to be related to nft > and how python3.8 calls nft and retrieves the results. > > Sep 8 01:52:56 localhost audit[1]: SERVICE_START pid=1 uid=0 > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 > msg='unit=systemd-coredump@0-1096-0 comm="systemd" > exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' > Sep 8 01:52:56 localhost systemd[1]: Started Process Core Dump (PID > 1096/UID 0). > Sep 8 01:52:56 localhost systemd[1]: firewalld.service: Main process > exited, code=dumped, status=11/SEGV > Sep 8 01:52:56 localhost systemd[1]: firewalld.service: Failed with result > 'core-dump'. > Sep 8 01:52:56 localhost audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 > ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=firewalld > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? > res=failed' > Sep 8 01:52:56 localhost systemd-coredump[1097]: Process 868 (firewalld) of > user 0 dumped core.#012#012Stack trace of thread 868:#012#0 > 0x00007f3d459e38d4 erec_print (libnftables.so.1.0.0 + 0x428d4)#012#1 > 0x00007f3d459e3d32 erec_print_list (libnftables.so.1.0.0 + 0x42d32)#012#2 > 0x00007f3d459e997c nft_run_cmd_from_buffer (libnftables.so.1.0.0 + This trace clearly show the crash occurs in the libnftables. erec_print() is called after an error occurs. It's trying to print errors to standard error. This example is a libnftables crash/bug. Not a firewalld bug.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.