Hide Forgot
Description of problem: zabbix_server_mysql fails to start when executed under systemd on Fedora 15. Version-Release number of selected component (if applicable): Name : zabbix-server-mysql Arch : x86_64 Version : 1.8.5 Release : 1.fc15 How reproducible: 100% Steps to Reproduce: 1. `/etc/init.d/zabbix-server start` or `systemctl start zabbix-server.service` 2. 3. Actual results: systemd thinks that it started (status confirms that it is running), when it isn't (there are no processes running) Expected results: running zabbix_server_mysql processes Additional info: This is a fresh x86_64 install of F15 with selinux enabled. The database was restored from a backup, and initially I was using a config file from F14, however to ensure that the config file was not the source of the issue, I removed the packages, renamed the config file, reinstalled the packages and then repopulated the relevant DB values in the config file. I did not wipe the database yet, as the startup does not get close to touching the database before it fails. I did quite a bit of searching before narrowing it down to being executed under systemd. When I execute zabbix_server_mysql straight from the bash (outside of the init scripts/systemd containers), it starts up fine and begins monitoring everything that it is configured to. When I start it under systemd, however, on initial process creation: * The setpriority() call fails with permission denied, [pid 11880] setpriority(PRIO_PROCESS, 0, 5 <unfinished ...> [pid 11877] exit_group(0) = ? Process 11874 resumed Process 11877 detached [pid 11880] <... setpriority resumed> ) = -1 EACCES (Permission denied) [pid 11880] write(2, "zabbix_server_mysql [11880]: ", 29) = 29 [pid 11880] write(2, "Unable to set process priority t"..., 53) = 53 * The semget() call fails with permission denied, [pid 11880] semget(0x7a0307a8, 9, IPC_CREAT|IPC_EXCL|0600 <unfinished ...> [pid 11881] <... close resumed> ) = 0 [pid 11874] <... rt_sigprocmask resumed> [], 8) = 0 [pid 11881] open("/lib64/libc.so.6", O_RDONLY) = 3 [pid 11880] <... semget resumed> ) = -1 EACCES (Permission denied) * and then (I believe) as a result of the failed semaphore creation, the mutex fails to be created as a whole, and all of this is logged to zabbix_log: zabbix_server_mysql [11880]: Unable to set process priority to 5. Leaving default. zabbix_server_mysql [11880]: Can not create Semaphore [Permission denied] zabbix_server_mysql [11880]: Unable to create mutex for log file and the server fails to start. Again, if I simply execute `zabbix_server_mysql` then everything starts up without issue. Commenting out the LogFile config statement does not resolve this problem.
Oh, both the failures (setpriority and semget) are in fact SELinux issues if I see the logs correctly. You can switch the system to the permissive mode with "setenforce Permissive" and zabbix should start.
Yes, that seems to have fixed it. I could have sworn that I checked audit.log when I was first checking through this and didn't see anything though -- oh well. I will upload the relevant audit.log entries when I get home. If I switch selinux back to enforcing after it has started, will that cause any issues?
Created attachment 502939 [details] relevant audit.log entries
I don't get zabbix_server_pgsql running with a fresh F15 and fresh Zabbix. Selinux is permissive. Neither running "service" nor "systemctl" achieve what they should. Systemd's status says "Active: active (exited) ...". No processes exist. I had to create the /var/run/zabbix directory though, to get it working with /usr/sbin/zabbix_server.
Should have been /usr/sbin/zabbix_server_pgsql in the last line.
Volker, systemd will clean up the /var/run/zabbix directory when you stop the service, so having to create this directory is expected. It would seem that zabbix_server_pgsql is just as broken as zabbix_server_mysql, though.
zabbix-1.8.5-3.fc15 (now waiting to be pushed into updates-testing) contains the fix for the /var/run/zabbix issue
Kyle, please turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent dac_override means there exists a file with bad ownership/permissions.
*** This bug has been marked as a duplicate of bug 674627 ***
Oops not really a dup.
Created attachment 503367 [details] full audit log Attached is the full audit log.
Ok I just updated the pool with fixes for your problems. Will be in selinux-policy-3.9.16-29.fc15
This still fails to start via systemctl with selinux-policy-3.9.16-30.fc15. Executing zabbix_server_mysql still works great. Is any other information needed?
Please attach the latest AVC's you are seeing?
Created attachment 513501 [details] SELinux and zabbix_server_pgsql
There is no /lib/systemd/*/zabbix-server.service file so systemctl shouldn't be use to start zabbix. To solve I just put SYSTEMCTL_SKIP_REDIRECT=true before the call for /etc/rc.d/init.d/funtions in the init script file for zabbix-server in /etc/init.d/zabbix-server
Created attachment 527453 [details] ausearch results for recent f15 install + zabbix_server_mysql Sorry for the bug negligence.. I just moved my zabbix install to another fedora machine and hit this again, and then remember that it was never full fixed, because I never gave everything that was needed. :) Attached is the full results of the `ausearch -m avc -ts recent` for a brand new (but full updated) F15 install.
This is now working under F16.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping