Red Hat Bugzilla – Bug 720065
Provide native systemd unit file
Last modified: 2012-04-03 14:57:55 EDT
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 512004 [details]
Native systemd service file for zabbix agent
Created attachment 512005 [details]
Native systemd service file for zabbix server mysql
Created attachment 512006 [details]
Native systemd service file for zabbix server pgsql
Created attachment 512007 [details]
Native systemd service file for zabbix server sqlite3
Created attachment 512009 [details]
Native systemd service file for zabbix proxy mysql
Created attachment 512010 [details]
Native systemd service file for zabbix proxy pgsql
Created attachment 512011 [details]
Native systemd service file for zabbix proxy sqlite3
I would like to recommend that the proxy and server conf be split into spesific settings conf file to their relevant type for example .
zabbix server sqlite3 would be started with...
ExecStart=/usr/sbin/zabbix_server_sqlite3 -c /etc/zabbix/zabbix_server_sqlite3.conf
and the configuration file tailored in the above example to sqlite3 server only
Same goes for the proxy agents
To keep the backwards compatability ( service zabbix-server start ) with the proxy and server agent you will need to create a symbolic link at their install time like so..
Continuing with sqlite3 example
For zabbit server sqlite3 it would be
ln -s /lib/systemd/system/zabbix-server-sqlite3.service /lib/systemd/system/zabbix-server.service
For zabbit proxy sqlite3 it would be
ln -s /lib/systemd/system/zabbix-proxy-sqlite3.service /lib/systemd/system/zabbix-proxy.service
We really need to get this stuff in place ASAP. Currently on F16 this causes zabbix-server to fail to start because it gets started before the database.
Note that in F16 the window to provide native systemd unit files has passed thus requiring an exception from fesco should it be introduced to the distribution via update anyway regarding your problem just add the relevant dbfoo.service to the After= line in the relevant unit file and that unit will be started after the relevant db has started...
As a workaround, I copied /lib/systemd/system/mysqld.service to /etc/systemd/system/ and added: