Problem description: attempting to start Zabbix agent in a FreeBSD jail fails with similar output to Zabbix’ log file:
zabbix_agentd : cannot create Semaphore:  Function not implemented zabbix_agentd : unable to create mutex for log file
jail_sysvipc_allow="YES" in rc.conf on the host:
# echo 'jail_sysvipc_allow="YES"' >> /etc/rc.conf
that’s on the host, not jail. Then restart the jail(s). This should work at least with ezjail.
In order to change this setting on a running jail, find the jail ID with
jls, then on host run:
# jail -m jid=7 allow.sysvipc=1
The longer explanation:
The issue is that Zabbix wants to use sysV IPC, but that’s disabled by default because it’s a major security risk. Details in the handbook. IPC stands for “inter process communication” a way for processes to talk to each other about what they’ve done and what their plans are (yes, really). In sysV IPC shared memory is used and access to this memory is given based on UID. Which means that, to paraphrase the handbook, if sysvipc is enabled it defeats the whole purpose of having a jail since users from the jail will be able to affect processes outside the jailed environment. root (UID 0) in jail can access the shared memory used by root (UID 0) on host and other jails. Hence, major security issue. Likewise, Zabbix in jail and Zabbix on host or other jails, if they are using the same UID, which they usually are. Weather this goes beyond security risk into actual functionality problem, I have no idea.
The above is further complicated if jails are set up using ezjail. Supposedly (I didn’t actually test) when setting jails from rc.conf or by using jail, it’s possible to set this variable per-jail, thus potentially mitigating some of the damage. However, I wasn’t able to do it using ezjail. In theory it should be done by adding/editing
in /usr/local/etc/ezjail/JAILNAME file, but I wasn’t able to get it to work.
The same thing applies to PostgreSQL, which also uses shared memory.