-
Incident report
-
Resolution: Unresolved
-
Trivial
-
None
-
2.2.18, 3.0.9, 3.2.5, 3.4.0alpha1
-
All
If the zabbix server is terminated before being able to connect to the database, it will not destroy the shared memory segments and semaphores properly, leaving them allocated in the OS.
To reproduce:
- Start the zabbix server with incorrect database parameters, so it will wait on startup
- Check with the ipcs command the allocated shared memory segments and semaphores:
$ ipcs Message Queues: T ID KEY MODE OWNER GROUP Shared Memory: T ID KEY MODE OWNER GROUP m 131120 1745428913 --rw------- abs abs m 65585 2013864369 --rw------- abs abs m 65586 1946755505 --rw------- abs abs m 65587 1728651697 --rw------- abs abs m 65588 1929978289 --rw------- abs abs m 65589 1393107377 --rw------- abs abs m 65590 1980309937 --rw------- abs abs Semaphores: T ID KEY MODE OWNER GROUP s 327680 2047418801 --rw------- abs abs
- Stop the zabbix server using either kill or pkill and sending SIGTERM:
$ pkill -TERM zabbix_server
- Run ipcs again.
- The memory segments and semaphores will still be there.
2.2, 3.0 and 3.2 leak both shared memory and semaphores. Trunk, after ZBXNEXT-3687 went in, leak only one semaphore