Applicable to:
- Plesk for Linux
Symptom
- Plesk Obsidian 18.0.52 or higher running on a Linux-based operating system
-
Plesk Firewall cannot be started after firewall rule adjustments, while displaying an error that is similar to the following
PLESK_ERROR: Command '['/usr/local/psa/var/modules/firewall/firewall-emergency.sh']' timed out after 5 seconds
- The workaround from the Plesk Firewall can not be enabled in Plesk 18.0.52 and newer: I did not receive connectivity confirmation after applying new firewall configuration article does not manage to resolve the issue
Cause
The start of iptables on the server's Linux OS is very slow due to hardware issues. Due to this, the majority of time is spent communicating with the kernel subsystem. The following is a comparison between the speed of execution for iptables-related commands on a properly working system versus the same on a server that has some hardware-related issue.
The test you may run in order to compare the time it takes to execute changes is the following:
1. Save iptables rules to a regular txt file:
# iptables-save > rules-saved-4.txt
2. Check the time it would take to restore these same rules to iptables by executing the following command:
# time strace -f -c iptables-restore < rules-saved-4.txt
Example output for server with hardware issues that are causing the slowdown:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.74 0.384871 128290 3 sendmsg
0.05 0.000198 8 23 recvmsg
0.05 0.000186 13 14 sendto
0.02 0.000095 1 54 mmap
0.02 0.000083 1 55 1 openat
0.02 0.000081 0 87 read
0.02 0.000072 1 42 mprotect
0.02 0.000065 0 73 close
0.01 0.000045 0 61 lseek
0.01 0.000037 0 55 fstat
0.01 0.000027 1 18 socket
0.01 0.000027 2 13 1 connect
0.00 0.000016 5 3 munmap
0.00 0.000014 0 21 getsockname
0.00 0.000011 0 13 6 stat
0.00 0.000010 0 13 bind
0.00 0.000008 2 3 select
0.00 0.000006 1 5 brk
0.00 0.000004 2 2 setsockopt
0.00 0.000001 0 2 1 arch_prctl
0.00 0.000000 0 2 rt_sigaction
0.00 0.000000 0 1 rt_sigprocmask
0.00 0.000000 0 1 1 access
0.00 0.000000 0 1 execve
0.00 0.000000 0 2 futex
0.00 0.000000 0 1 set_tid_address
0.00 0.000000 0 1 set_robust_list
0.00 0.000000 0 1 prlimit64
------ ----------- ----------- --------- --------- ----------------
100.00 0.385857 676 570 10 total
real 0m13.340s
user 0m0.011s
sys 0m0.398s
Example output for server that is not experiencing hardware issues:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
21.18 0.000591 39 15 socket
11.11 0.000310 6 50 mmap
10.46 0.000292 292 1 execve
6.84 0.000191 3 56 read
6.84 0.000191 63 3 sendmsg
6.49 0.000181 8 22 openat
5.66 0.000158 3 40 mprotect
5.37 0.000150 13 11 sendto
5.12 0.000143 13 11 4 stat
4.48 0.000125 3 38 close
3.98 0.000111 3 31 lseek
3.51 0.000098 4 20 recvmsg
2.65 0.000074 5 13 1 connect
2.01 0.000056 2 24 fstat
1.50 0.000042 2 18 getsockname
1.22 0.000034 3 10 bind
0.64 0.000018 18 1 1 access
0.32 0.000009 1 5 brk
0.25 0.000007 3 2 setsockopt
0.18 0.000005 2 2 1 arch_prctl
0.18 0.000005 2 2 futex
0.00 0.000000 0 2 munmap
0.00 0.000000 0 2 rt_sigaction
0.00 0.000000 0 1 rt_sigprocmask
0.00 0.000000 0 3 select
0.00 0.000000 0 1 set_tid_address
0.00 0.000000 0 1 set_robust_list
0.00 0.000000 0 1 prlimit64
------ ----------- ----------- --------- --------- ----------------
100.00 0.002791 7 386 7 total
real 0m0.030s
user 0m0.007s
sys 0m0.013s
Resolution
Note: If the server is a virtual machine, you should check the hypervisor that controls it in order to determine a proper root cause
Due to the slow execution caused by hardware issues, as a workaround, you should increase the timeout of the Plesk Firewall extension to a higher value (for example 200 or 300 seconds) by doing the following:
1. Log into your server via SSH
2. Open the /usr/local/psa/admin/conf/panel.ini file for editing with your favorite command-line text editor
3. Place the following section at the bottom of the file:
CONFIG_TEXT: [ext-firewall]
confirmTimeout = 300
4. Save the changes
Comments
2 comments
This is absolutely not the reason Firewall doesn't start. I can't start the firewall, but my iptables time is negligible, about 0.081s
It has everything to do with the Extension instead of being a core service.
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
29.29 0.000902 23 38 mmap
22.40 0.000690 690 1 execve
5.75 0.000177 14 12 sendto
5.75 0.000177 19 9 openat
5.36 0.000165 11 14 close
4.19 0.000129 8 15 recvmsg
4.09 0.000126 42 3 sendmsg
3.96 0.000122 12 10 read
3.77 0.000116 16 7 3 newfstatat
3.41 0.000105 10 10 fstat
2.73 0.000084 21 4 socket
2.31 0.000071 7 10 mprotect
1.49 0.000046 11 4 bind
1.23 0.000038 9 4 getsockname
0.78 0.000024 4 6 munmap
0.71 0.000022 11 2 pread64
0.49 0.000015 15 1 1 access
0.49 0.000015 5 3 setsockopt
0.32 0.000010 2 4 brk
0.32 0.000010 10 1 rseq
0.29 0.000009 9 1 arch_prctl
0.29 0.000009 9 1 set_tid_address
0.29 0.000009 3 3 pselect6
0.29 0.000009 9 1 set_robust_list
0.00 0.000000 0 1 getuid
0.00 0.000000 0 1 geteuid
0.00 0.000000 0 1 prlimit64
0.00 0.000000 0 1 getrandom
------ ----------- ----------- --------- --------- ----------------
100.00 0.003080 18 168 4 total
real 0m0.062s
user 0m0.008s
sys 0m0.019s
If the situation described in this article does not apply to your specific server environment, submit a ticket to Plesk support, so that proper investigation for your specific situation can be carried out.
Please sign in to leave a comment.