Imunify service starts and fails shortly after. Python segfaults can be spotted in log messages like:
python3: segfault at 0 ip 00007f9d7ea73bc6 sp 00007f9d5d97f920
error 4 in libc-2.28.so[7f9d7e9ee000+1bc000]
- Python 3
To fix the error, it is necessary to update the kernel on the server and reboot the server with the new kernel after that. Use the package manager features and the uname -a command to make sure that the server is loaded with the updated kernel.
While the running service can be straced with:
It makes sense to look at service uptime:
systemctl status imunify360
If it persists for an hour or more and no Python segfaults are in logs, this article is likely inapplicable. Just bear in mind that segfaults are not only due to bad code but can be caused by the kernel.
Some tracebacks more often lead to thread.py than those do to other modules:
Fatal Python error: Segmentation fault
Current thread 0x00007fe23bfff700 (most recent call first):
<no Python frame>
Thread 0x00007fe241483700 (most recent call first):
File "/opt/alt/python38/lib64/python3.8/concurrent/futures/thread.py", line 78 in _worker
File "/opt/alt/python38/lib64/python3.8/threading.py", line 870 in Segmentation fault (core dumped)
Yet overall, tracebacks are sporadic.
Segfaults like SEGV_MAPERR can also be caused by the kernel managing the task sizes while kernel update is pended. For example, when "yum update" was executed but the loaded kernel is not yet the new.