> > > OK.  You don't have to write OCF scripts if you don't want to.  BUT, for
> > > R2, you really do want something equivalent to "status" operations.  Is
> > > that available in *BSD rc.d scripts?
> > 
> > /etc/rc.d/<script> status
> > 
> > Does that do what you want?
> 
> Well...
> 
> OCF resource agents also have a (hopefully) more thorough test called
> "monitor".   That's a value add over "status" (at least to some degree), as
> are a number of other things it does...
> 
> But speaking from a minimum requirements basis:
> 
> If status returns a reliable return code it probably meets the minimal needs.
> Minimally there needs to be at least two distinct classes of return codes:
> one for running and one for not running.  Optimally, there ought to be at
> least three:  Running, stopped, and something's-wrong-here.
> 
> Is there some kind of metadata (description, etc) that one can mechanically
> get out of the scripts?  In LSB init scripts, there is a certain style of
> comment which makes it possible for us to give some help to the user in
> configuring these resources.
> 
> If such information can be obtained from BSD init scripts, then so much the
> better.  (It's not strictly necessary, but it is nice).

I didn't see anything else posted about this on the FreeBSD 
freebsd-rc or NetBSD tech-userlevel lists ...

Our rc.d system does have a monitor. Will this work:

  $ sudo /etc/rc.d/cron poll
  Waiting for PIDS: 21395, 21395, 21395, 21395

and continues forever (checking every two seconds) until PIDs do not 
exist.

Is this the type of monitoring you are mentioning?

The rc.d "status" does return a status code.

If not running, then it returns a 0 (zero). If it is running, it returns a 
1 (one). It also says "... is not running" or "... is running as pid 
.....".

There is no metadata you can retrieve from the scripts.

By the way, they are not call BSD init scripts. Some BSD operating systems 
do not use them.

They originated in NetBSD a few years ago. FreeBSD's are based on these, 
but have been slowly diverging. (On a side note, we need to go through the 
changes and improvements between NetBSD's , FreeBSD's, and DragonFly's 
rc.subr to see if we can keep this code closer in sync. I am not 
suggesting the rc.d scripts should be same though.)

 Jeremy C. Reed

p.s. I also use NetBSD's rc.subr/rc.d system on various Linux boxes.