Initialisation Scripts Debian/Ubuntu

[DaveLevy]

I have been looking at the Systems V Initialisation scripts for the zabbix agent. I have started from the debian code and am testing using Ubuntu 9.

The code is not LSB compliant in a couple of ways and this means that installing the links using update-rc.d is more difficult than it otherwise might be. It may also fail to work with the red-hat based chkconfig which I have seen require certain comment lines. These are resolved by installing the mandatory comment block. See http://wiki.debian.org/LSBInitScripts. The code makes no use of the the /lib/lsb/init-functions; start-stop-daemon is part of dpkg utilities and is file system addressable binary. I plan to amend the script to include the comment block and use the log_msg functions.

The environment variables need to be made installation specific. The debian code assumes that there is a /home/zabbix/bin directory, which since the default location is /usr/local seems a bit odd, but the fact is that these variables need to be checked and fixed. Also the script appends ~/bin to the PATH and not ~/sbin. This is not right. Most importantly the PATH variable needs to be amended to include the location of the binary. The path would be best fixed in the ./configure script, but I don't plan to do this.

I have implemented a status method which relies on zabbix_get.

case $( zabbix_get -s127.0.0.1 -k agent.ping 2> /dev/null ) in
1)    exit 0 ;;
*)    exit 1 ;;
esac

Is this sensible? Does --enable-agent ensure the build of zabbix_get?

The help function assumes that the scriptname is the same as the program name. So I have coded a SCRIPTNAME variable. (I should probably have used $0.) The script name is only consumed in the help method. It is referred to using $0 in the restart method.

Ubuntu keeps its .pid files in /var/run which is a root:root directory. This means that the zabbix_agentd cannot write the PID there with the default configuration. I can think of a couple of ways round this.

I can change the permissions on /var/run to permit the zabbix user to write into it. I could use /var/tmp which is 777. I could create a /var[/run]/zabbix directory and chown it to zabbix. For the short term, I think I'll use /var/tmp. I assume that any attempt to use start-stop-daemon's --user or --group parameters will be overwritten by the zabbix binary. (If I test this, I'll update this thread.)

Additionally, the /etc/zabbiz/zabbix_agentd.conf defines where the zabbix agent writes the PID file and so we have the ablity to muck up here, with the script passing an erroneous pid file address to the start-stop-daemon program. I have replaced the code with the following

CONFIG_FILE=/etc/zabbix/${NAME}.conf
PID=$( cat $CONFIG_FILE | egrep ^PidFile= | cut -f2 -d"=" )

This fixes an error configuration I discovered. Both the zabbix_agentd and the start-stop-daemon now use the same PID file. This involves invoking external programs, but we only run this occasionally and they're both in bin.

I have placed a sleep 3 between the start and stop calls in the restart|force-reload method. It seems to prefer this. I would have prefered to code the methods as functions and invoked the functions from the method case selection statement but I have left it as it is for the moment. Reusing the code, which this does is the better thing to do IMO.

I have attatched the whole file if you want to read it. If the Zabbix committers like what I have done, perhaps they'll include it in the distribution. Anyone please comment to improve this code.

For Ubuntu I am going to use the LSB functions to use the log* functions to control the console display.

I shall next look at the Fedora server script.

[James Wells]

Greetings,

I have been looking at the Systems V Initialisation scripts for the zabbix agent. I have started from the debian code and am testing using Ubuntu 9.

Hanve't looked at what you have done so far, but you might want to look at the Ubuntu / Debian Zabbix package. I say this because, while it is not fully LSB compliant it comes a lot closer than the init scripts that come with the Zabbix source tarball.

Also the script appends ~/bin to the PATH and not ~/sbin. This is not right. Most importantly the PATH variable needs to be amended to include the location of the binary.

Again, this is done mostly correct with the existing Ubuntu / Debian package. I say mostly correct, because the existing builds install it as a normal system package, instead of a standalone package. Zabbix should never be installed under home or /. It is an optional - standalone package, therefore it should be installed under /opt. But that is just my opinion.

Does --enable-agent ensure the build of zabbix_get?

--enable-agent, causes the building of zabbix_agent, zabbix_agentd, zabbix_sender, and zabbix_get. --enable-server causes the building of zabbix_server and zabbix_proxy.

Ubuntu keeps its .pid files in /var/run which is a root:root directory. This means that the zabbix_agentd cannot write the PID there with the default configuration. I can think of a couple of ways round this.

Again, this is one of those areas where the maintainer of the Ubuntu / Debian package get's it almost right. What they have done in following the new Ubuntu / Debian standard is they are creating /var/run/<package> directory, during service start, and storing the PID files there. Where I disagree with them, is that there are now a /var/run/zabbix-agent and a /var/run/zabbix-server directories.

I have placed a sleep 3 between the start and stop calls in the restart|force-reload method.

This might be too little, or too long depending on your usage. For example, I have an environment where 3 seconds is too short as the agent and server cannot unbind ports until sub scripts are completed. A better way to do this is to sleep until the port in unbound, then start the new service.

[DaveLevy]

V1.3

Thanks for your reply.

I was aware that Ubuntu have packaged Zabbix but I want to use the more recent versions. I agree that I should inspect the package but I coldn't be bothered to create another VM to install it into. Perhaps I should.

Not sure about /opt, I'd expect the Ubuntu packagers to install the binaries into /usr/[s]bin, with links to into /usr/bin but I am not sure they get it right either.

Thanks for your suggestions/insights on the sleep and pid file location. (The latter would explain why the samba scripts uses the install command to create the directories. I will/may fix this some time.)

I have attatched my next version of the script which uses the log_*_msg functions from /lib/lsb/init-functions.

[richlv]

thanks for the work on the script. regarding the agent daemon status, i think it's not safe to rely on zabbix_get :

1. agent might not allow local connections, only from zabbix server, thus this test would fail;
2. agent might be configured to use active checks and the initscript test would fail again;
3. if there would be some firewall rules, it would just fail, or (worse) timeout;
4. agent might be running on a different port

and maybe some other possibilities...

i guess it's best to rely on distro standard functions that usually check whether process with the expected name is running as th expected pid.

[DaveLevy]

Self test is best

What you say is not wrong, but I strongly believe that if a service has diagnostics then these should be used in the status method.

When writing something simple such as a method for a single process daemon which is running or not, then the LSB way of doing things is OK, although I am not a fan of creating and using pid files; you may create a dependency on other services functioning correctly. Zabbix agent is simple, and would probably work, the server is not.

As I said, I believe that a service's own functionality should be used to self test.

WRT to your use cases

1. Yup, not good.
2. Possibly a killer, is there a developer response. I suppose only if you agree with me that self tests are better than pid files etc.
3. Shouldn't be a problem, I am using the loopback address
4. I considered coding for this, but decided not to. You have registered the port. I think that any installer that changes the ports, can probably hack the script. Maybe I'll make the port an env variable so that its obvious where to put the code to check the config file to the port.

I also consider UNIX compatability when writing these things.

Hope you guys find it useful. (I should finish it and write a server version).

[richlv]

What you say is not wrong, but I strongly believe that if a service has diagnostics then these should be used in the status method.

in general, i agree - but only if they are reliable for most/all users

WRT to your use cases

1. Yup, not good.
2. Possibly a killer, is there a developer response. I suppose only if you agree with me that self tests are better than pid files etc.

hmm, what kind of a response ? i don't see a feasible way for that to work with an active agent...

3. Shouldn't be a problem, I am using the loopback address

ah, but then we get to another issue that i didn't mention in my initial list - ListenIP directive...

4. I considered coding for this, but decided not to. You have registered the port. I think that any installer that changes the ports, can probably hack the script. Maybe I'll make the port an env variable so that its obvious where to put the code to check the config file to the port.

well, "variablising" the port would be trivial. requiring it's update would be a bit cumbersome, but yeah, not the biggest issue i guess.

but stepping a bit back from the details, we should look at the purpose of the initscript. i'd say that it's purpose is to start and stop the daemon. that's it. if it's running, initscript shouldn't be concerned about intricate internal details of it.
of course, we would want to monitor these things... hey, that's what zabbix might be good at
so simple agent.ping check would catch agent unavailability. i'd suggest going with standard initscript functionality, and check proper agent operation with zabbix itself.

[DaveLevy]

More news, but not much

I have just had reason to use this script again.

It is not clever that I use an absolute path name to define the location of the zabbix agent daemon, and an inherited location from the PATH for zabbix_get.

I have stuck with /var/tmp for the location of the pid file and log file.