ctdb event scripts

[Steve French]

On Fri, Nov 11, 2016 at 11:30 AM, Martin Schwenke <martin at meltin.net> wrote:

> On Fri, 11 Nov 2016 10:43:32 -0600, Steve French <smfrench at gmail.com>
> wrote:
>
> > On Thu, Nov 10, 2016 at 7:39 PM, Martin Schwenke <martin at meltin.net>
> wrote:
> >
> > > On Thu, 10 Nov 2016 19:06:50 -0600, Steve French <smfrench at gmail.com>
> > > wrote:
> > >
> > > > ctdb event scripts are run automatically - but sometimes for
> debugging it
> > > > would be useful to run one or more scripts (at least the monitoring
> part
> > > of
> > > > them) manually with output displayed to stdout.  Has anyone
> experimented
> > > > with doing this?
> > >
> > > You should be able to run an event script by hand and give "monitor" as
> > > an argument.
> > >
> > >
> >
> > That works and is useful - but dumps to a log so a little harder to read
> > for quick checks.
>
> Oh, I didn't mean "ctdb eventscript monitor".  I meant something like:
>
>   /etc/ctdb/event.d/50.samba monitor
>
> There is enough boilerplate in the scripts so that they can find the
> functions file and the configuration.
>
> CTDB won't notice that you're running it, unless it stores state and a
> subsequent run by CTDB uses that state.  For example, 60.nfs counts
> RPC failures before failing the "monitor" event.  If you run a script by
> hand it will update the same state.
>
> Alternatively, if you just want to know why a monitor cycle failed
> without grovelling through logs, you can always see the output of the
> last monitor cycle by running:
>
>   ctdb scriptstatus monitor
>
> Cool feature idea: implement an option to scriptstatus that shows the
> output of the last failure.  This would require daemon support, since
> that's where the information comes from.
>
> peace & happiness,
> martin
>

Yes - that is a cool idea.

I have been mulling over ways to check other services too (nfs kernel
service stuck e.g.,   or a systems management process stuck) - ctdb
eventscripts are interesting



-- 
Thanks,

Steve