[ZBX-12123] Zabbix server leak semaphores and shared memory on termination Created: 2017 Apr 28  Updated: 2020 Nov 02

Status: Open
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: 2.2.18, 3.0.9, 3.2.5, 3.4.0alpha1
Fix Version/s: None

Type: Incident report Priority: Trivial
Reporter: Andrea Biscuola (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: memory, semaphores, shared
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


 Description   

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
Generated at Sat Apr 27 01:05:00 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.