Do package control scripts necessarily have to be shell scripts?

[Ralph Grothe]

Hi,

I'm fiddling a bit with the package control scripts of our toy cluster.

Doing this, I've come to the conclusion that being forced (by whom?) to resort to HP-UX's standard shell (or any) is obnoxoius.

See my attachment as a deterrent example of adding most essential functionality to the
/etc/cmcluster//.cntl
script in a very clumsy way.
Here I just want to define a few more variables that I could use in the
customer_defined_(run|halt)_commands functions by calling this init() function.

How easy and efficiently could such a simple task be done in Perl.

Thus I would wish I could replace all of the packages' control scripts by custom Perl scripts.

Is SG-wise anything opposing to my wish.

I guess a lot of variables will have to be exported, as the control scripts seem to be sourced by the cm(run|halt)pkg processes at package start and halt.

Suggestions are welcome.

[Stefan Farrelly]

Hi Ralph,

I dont know anyone who has tried/done this before but I dont see why you cant use perl. All you have to do, as you said, is handle all the variable assignments and ensure error checking is the same as for a shell script (a call to a script returning 0/1 - your perl program will need to do the same).

As long as you test its lots I dont see why it wont work.

[Duncan Edmonstone]

Ralph,

I don't like fiddling with the basic structure of a package control file, mainly because these *do* get changed in newer releases of ServiceGuard, and who am I to say whether these changes are not reflected by logic changes in the ServiceGuard binaries.

What I always do is have my customer_defined_(run|halt)_commands as a one liner which calls a seperate script - this seperate script can be anything I like, be it shell, perl or even a compiled C program - as long as it returns 0 on success it doesn't matter what it is. - for example:

customer_defined_run_commands()
{
start_db.pl
test_return 51
}

customer_defined_halt_commands()
{
stop_db.pl
test_return 52
}

Then all you clever code can get tucked away in your own seperate scripts without upsetting ServiceGuard.

Is there a reason this approach won't work for you?

Duncan