Toggling firewall is (too) slow

[ALinuxUser]

I have a laptop that runs reasonably fast. Yet, toggling the firewall on and off takes about four seconds - which is long enough to make the user wonder whether s/he has made the wrong gesture.

Mint 18 Cinnamon. Gufu 16.04.1. Intel dual-core T7500 @ 2.20GHz, 8GB RAM, on an SSD. Fast Ethernet (75MBits) and reasonable (between 75 and 20Mbits) wifi.

[Jamie Strandboge (jdstrand)]

ufw is a python3 program and as such, there is some overhead with loading the python3 interpreter. However, on a constrained device I see:

$ time sudo ufw --force enable
Firewall is active and enabled on system startup

real 0m0.301s
user 0m0.100s
sys 0m0.028s

I'm not sure why it is so slow on your system. Please provide detailed configuration and steps to reproduce along with strace output to justify this is a bug in ufw and I can take a look at what is happening.

Thanks!

[ALinuxUser (buntulongername-new)]

Thanks.

Here's the output of that command (not that I understand the command) on my system.

time sudo ufw --force enable
Firewall is active and enabled on system startup

real 0m3.808s
user 0m0.188s
sys 0m0.092s

My system is a Dell D830 laptop with a SSD and the following specifications. (These specs are slightly more comprehensive than the ones I provided in my first post.)

OS: Linux Mint 18 Sarah x86_64
Kernel: 4.4.0-45-generic
DE: Cinnamon
CPU: Intel Core2 Duo T7500 (2) @ 2.2GHz
GPU: Intel Integrated Graphics
Memory: 7974MB

Steps to reproduce the problem: open GUFU, turn firewall on or off.

As to Strace: I have never used it before. Please specify the command(s) you wish me to run and the output you wish me to pass on.

[Jamie Strandboge (jdstrand)]

Please perform:

$ sudo tar -zcvf /tmp/ufw.tar.gz /etc/ufw /lib/ufw

and attach /tmp/ufw.tar.gz to the this bug. If you'd prefer to email me privately, you can go to https://launchpad.net/~jdstrand to find my email address.

[ALinuxUser (buntulongername-new)]

Thanks. I've emailed you, using the first address in the list.

[ALinuxUser (buntulongername-new)]

Let me refine one of my previous statements. I said that 'toggling the firewall on and off takes about four seconds'. A more accurate report is as follows. Turning the firewall off takes approximately five seconds and turning it back on takes approximately three seconds.

[Jamie Strandboge (jdstrand)]

Thank you for sending me your ruleset. On a constrained system I don't see any problems:

$ time sudo ufw disable
Firewall stopped and disabled on system startup

real 0m0.193s
user 0m0.100s
sys 0m0.016s

$ time sudo ufw --force enable
Firewall is active and enabled on system startup

real 0m0.322s
user 0m0.096s
sys 0m0.060s

This is less than .2 seconds to disable and just over .3 secconds to enable. This does not appear to be a bug in ufw per se and seems system specific. I checked if removing the .pyc files slowed ufw much (eg, on Ubuntu 16.04: 'sudo rm -f /usr/lib/python3/dist-packages/ufw/__pycache__/*') and it doesn't on amd64 (which based on your bug description, yours is also).

I suspect your system is under high load, memory pressure, etc. For now, I'm going to mark this as 'Invalid' but feel free to comment if you discover this is an issue with ufw and not a local issue.

[ALinuxUser (buntulongername-new)]

Thanks. However, (1) my system is not 'under high load, memory pressure'. For, I have the problem when there is over 6GB of RAM available for use, no swap in use (but almost 10GB of SSD swap available) and when the CPU activity is low. Perhaps you should try out GUFU on a low-to-medium end Linux Mint Cinnamon system and see if you experience the problem.

Also, I do not know (nor did a simple web search tell me) what a constrained system is.

[Jamie Strandboge (jdstrand)]

What I meant by a constrained system was one with low memory and one CPU. This was not a problem here. The only thing I can think of on why it would be slow would be if on Mint they don't generate the .pyc files. Python will byte-compile on first run and generate .pyc files so that on subsequent runs the compile can be avoided. This is known to have a significant impact on ARM systems. I tested that scenario locally on an amd64 system using Ubuntu and deleting the .pyc files did not have a significant impact, but perhaps on your system this is the case? Perhaps python is otherwise slow on Mint due to compile options or something similar?

You can see if you have .pyc files on your system with "find /usr -name '*.pyc' | grep ufw" (assuming Mint stores them there). If they aren't there or other python programs are slow, I suggest filing a bug with Mint.

[ALinuxUser (buntulongername-new)]

Right - I will report this to mint. (The files in question do seem to be there, though.)

[Thomas SIMON (dev.uhuru)]

Hello, has a solution for this problem been found? I understand that it might not be ufw, but looking for some information and it's hard to find. I seem to have the same issue that OP has with approx. 4 seconds to disable and 5 seconds to enable (on Ubuntu 20.04). Many thanks in advance.

[Jamie Strandboge (jdstrand)]

Thomas, this report is about Mint, not Ubuntu. While 4 or 5 seconds is certainly not fast, there are many factors that could affect why it is slow. Please review the other comments in this bug and if so inclined, file a new bug with steps to reproduce along with details related to those comments.