FirewallD class generation does not return (2.0.1)

[magic-object]

What happened

A phenomenon that appeared to be a memory leak occurred in firewalld (2.0.1), so I checked using PDB.

Then, the next class generation on line 89 of server.py did not return.

service = FirewallD(name, config.dbus.DBUS_PATH)

What you expected to happen

I thought the class generation would be successful.

How to reproduce it (as minimally and precisely as possible)

python -m pdb /usr/sbin/firewalld --nofork --nopid

Anything else we need to know?

It feels like something is consuming a large amount of memory.

Firewalld Version

2.0.1

Firewalld Backend

No response

Linux distribution

Fedora39

Linux kernel version

6.5.11

Other information

No response

[thom311]

It feels like something is consuming a large amount of memory.

I think this report is not actionable. Needs more information...

[magic-object]

After starting firewalld, I checked the memory usage using the memstrack command and found that it was consuming a large amount of memory.

---

'q': quit, 'r': reload symbols, 'm': switch processes/modules, 'p': pause UI
Pages being tracked: 171840 (671MB)
┌ PID | Pages | Peak | Process Command Line
│ 9035 | 148202 | 148202 | /usr/bin/python3 -sP /usr/sbin/firewalld --nofork --nopid │
│ 68 | 13898 | 13898 | (68) │
│ 2656 | 3441 | 7589 | /usr/bin/gnome-shell │
│ 459 | 852 | 852 | (459) │
│ 1366 | 848 | 849 | dovecot/imap │
│ 9504 | 789 | 1456 | /opt/google/chrome/chrome --type=renderer --crashpad-handler-pid=3748 --enable-crash-reporter=32d9332a-c40d-4158-b096-d5473ca7a02a, --disable-nacl --origin-trial-disabled-f │
│ 9491 | 565 | 6400 | /usr/sbin/CROND -n │
│ 5013 | 498 | 532 | php-fpm: pool www │
│ 1136 | 497 | 507 | php-fpm: pool www │
│ 1140 | 397 | 397 | php-fpm: pool www │
│ 9500 | 376 | 379 | /usr/lib/systemd/systemd-userdbd │
│ 9499 | 267 | 270 | /usr/lib/systemd/systemd-userdbd │
│ 4653 | 261 | 317 | /usr/libexec/gnome-terminal-server │
│ 8637 | 130 | 130 | /opt/google/chrome/chrome --type=renderer --crashpad-handler-pid=3748 --enable-crash-reporter=32d9332a-c40d-4158-b096-d5473ca7a02a, --disable-nacl --origin-trial-disabled-f │
│ 2844 | 89 | 89 | /usr/libexec/dconf-service │
│ 3963 | 73 | 74 | (3963) │
│ 9172 | 65 | 75 | /opt/google/chrome/chrome --type=renderer --crashpad-handler-pid=3748 --enable-crash-reporter=32d9332a-c40d-4158-b096-d5473ca7a02a, --disable-nacl --origin-trial-disabled-f │
│ 9174 | 40 | 43 | /opt/google/chrome/chrome --type=renderer --crashpad-handler-pid=3748 --enable-crash-reporter=32d9332a-c40d-4158-b096-d5473ca7a02a, --disable-nacl --origin-trial-disabled-f │
│ 9244 | 38 | 38 | (9244) │
│ 9303 | 36 | 37 | systemd-userwork: processing... │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

[magic-object]

After deleting /etc/firewalld/zones/drop.xml, it started without any problems.

[magic-object]

If /etc/firewalld/zones/drop.xml was a small file, firewalld started without any problems.

This seems to be a problem with large drop.xml files.

[magic-object]

drop.xml where the problem occurred

drop.xml.zip

[erig0]

You're using a large amount of zone sources. While we look at this issue I suggest using an ipset instead. Then add it to the zone with --add-source=ipset:<ipset>.

[magic-object]

thank you. I'll try it.