puppet and xinetd

I ran into an interesting problem with puppet today involving xinetd on CentOS 5. In one of my manifests, I had declared the following service resource:

<service { "xinetd":
    ensure    => stopped,
    enable    => false,
    hasstatus => true,
}

The problem I was seeing was every time the puppet client ran, it stopped the xinetd service:

Sep  5 01:10:21 someserver puppet-agent[2300]: (/Stage[main]/Xinetd/Service[xinetd]/ensure) ensure changed 'running' to 'stopped'
Sep  5 01:10:21 someserver puppet-agent[2300]: Finished catalog run in 5.82 seconds
Sep  5 01:20:33 someserver puppet-agent[2300]: (/Stage[main]/Xinetd/Service[xinetd]/ensure) ensure changed 'running' to 'stopped'
Sep  5 01:20:36 someserver puppet-agent[2300]: Finished catalog run in 11.55 seconds
Sep  5 01:30:43 someserver puppet-agent[2300]: (/Stage[main]/Xinetd/Service[xinetd]/ensure) ensure changed 'running' to 'stopped'
Sep  5 01:30:45 someserver puppet-agent[2300]: Finished catalog run in 6.13 seconds
Sep  5 01:40:58 someserver puppet-agent[2300]: (/Stage[main]/Xinetd/Service[xinetd]/ensure) ensure changed 'running' to 'stopped'
Sep  5 01:40:59 someserver puppet-agent[2300]: Finished catalog run in 10.68 seconds

Ultimately, the problem was with the startup script (/etc/init.d/xinetd). When running /sbin/service xinetd status when the service was stopped, the script was exiting with code 0 which means the process is running, and hence puppet will try to stop it. There’s a couple ways we could fix this. We could change hasstatus to false which will then instruct puppet to default to looking for xinetd in the process table, or we could fix the startup script. I opted for fixing the startup script because fixing it there protects against a couple of other types of failures not being correctly reported when checking the status (ie. the dead but pid file exists and dead but subsys locked). My fix is to simply change /etc/init.d/xinetd from this:

status)
        status $prog
        ;;

To this:

status)
        status $prog
        RETVAL=$?
        ;;

The right thing to do would be to patch and rebuild the rpm, but then I’d be maintaining an rpm for a service we barely use here in our environment. It looks like Fedora and CentOS 6 already have a fix for this.