Monday, September 26, 2005

Service status

I'm in the process of converting my cfengine configuration to a Puppet configuration, and I realized that, amazingly, Apache 2 on Debian does not provide a 'status' command in its init script. Even worse, when you call it with status as an argument, it prints a usage message but then exits with an exit code of 0, which means that I can't tell that it failed.

So, I figure, ok, maybe apache2ctl would do it for me. Nope, it tries to hit the local server's status.cgi script, but even if it gets a 404 it still exits with a return code of 0. This means, basically, that Apache 2 on Debian provides no way out of the box to automatically tell whether the service is running at all, much less running well, which kind of shoots my whole service management plan in the head. I was planning on relying on status commands on init scripts, but I obviously can't do that.

It looks like most platforms are moving to some kind of service manager -- Solaris 10's service manager is certainly highly touted, and Fedora (and, one assumes, Red Hat) has a 'service' command that does something similar. So, I need to redo service management so that it uses the local service manager if one is available, and if not then does what it can.

At this point I'm thinking about either allowing users to specify status commands (e.g., they would specify a command that searched through the process table), or maybe have a boolean 'hasstatus' flag that services support, so you could specify whether the init script should be used to get a status or whether Puppet should look in the process table. I don't think either of these is a particularly good solution.

Another idea I had, which is what I will probably go with, is to focus less on server status and more on whether a service is enabled or not. This would rely a bit too much for comfort on services being started at boot time and then never having any trouble (although, really, monitoring should probably used to discern trouble there), but it does seem to fit in better with how sysadmins actually work.

2 Comments:

At 7:01 PM, Blogger fishzle said...

Hi Luke,
I'd like my change control system to just do changes as I specify them. I have other monitoring systems (Openview, Solaris SMF) that watch for things that are supposed to be running/not supposed to be running.

I think it'd be better if puppet just did what it did well, rather than be a jack-of-all-tools. If I wanted that I'd probably choose to to re-implement puppet-on-emacs.

This should also reduce the complexity of puppet and make it more robust and reliable. Both of which are rather more essential characteristics than having all the bells and whistles.

cheers,
francis

 
At 8:19 PM, Blogger Luke Kanies said...

Well, at the least you need your config system to be able to specify that a service should or should not be configured -- make sure SSH is enabled, make sure portmap is disabled, etc. So we know we have to talk about services somewhat, the question is just how much.

For most systems (especially the more modern ones like launchd and SMF), it would be sufficient to just enable the services, but for the older init-style systems we need to, at the least, start the service when we enable it. Well, that, or reboot, but it's obvious we don't want that.

 

Post a Comment

<< Home