Greetings all,

I'm wondering if anyone has found a more elegant way of solving this
problem.

The situation:

I have two hosts that are SAN attached, but only the active (VxVM)
node can actually mount the filesystems on the SAN. I have a user on
both systems that needs to run a script via cron periodically and I
want to make sure the scripts that that user is running are the exact
same scripts.

My solution:

I have put the scripts on the SAN storage, and since only the active
node can "see" the scripts, only the cron jobs on that node will
succeed. My testing shows that the only ill effect thus far is a
"rc=1" entry for that job in the /var/cron/log on the passive node.

--

I'd like to be sure that I'm doing this as elegantly and as
efficiently as possible and not opening myself up to some kind of
problem in so doing. Anyone have any ideas on how to do this better?

Cheers,

pb

On Mon, 08 Oct 2007 23:12:46 -0000, pbeckhelm@gmail.com wrote:
> Greetings all,
>
> I'm wondering if anyone has found a more elegant way of solving this
> problem.
>
> The situation:
>
> I have two hosts that are SAN attached, but only the active (VxVM)
> node can actually mount the filesystems on the SAN. I have a user on
> both systems that needs to run a script via cron periodically and I
> want to make sure the scripts that that user is running are the exact
> same scripts.
>
> My solution:
>
> I have put the scripts on the SAN storage, and since only the active
> node can "see" the scripts, only the cron jobs on that node will
> succeed. My testing shows that the only ill effect thus far is a
> "rc=1" entry for that job in the /var/cron/log on the passive node.
>
> I'd like to be sure that I'm doing this as elegantly and as
> efficiently as possible and not opening myself up to some kind of
> problem in so doing. Anyone have any ideas on how to do this better?

You could always use something like:

5 * * * * /root/scripts/run.sh /path/to/real/script

and keep a local copy of `/root/scripts/run.sh' on each node, which
contains something like:

#!/bin/sh

if test ! -x $1 ; then
exit 0
fi

shift
exec $1 "$@"

But that sounds like a bit of overkill, and you still get to keep a
local copy of `run.sh' on each node :-/

Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> You could always use something like:
>
> 5 * * * * /root/scripts/run.sh /path/to/real/script
>
> and keep a local copy of `/root/scripts/run.sh' on each node, which
> contains something like:
>
> #!/bin/sh
>
> if test ! -x $1 ; then
> exit 0
> fi
>
> shift
> exec $1 "$@"
>
> But that sounds like a bit of overkill, and you still get to keep a
> local copy of `run.sh' on each node :-/

Might as well just do that in the crontab:

0 0 * * * [ -x /path/to/script ] && /path/to/script


--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

On Tue, 09 Oct 2007 00:21:22 GMT, ddunham@taos.com (Darren Dunham) wrote:
>Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
>> You could always use something like:
>>
>> 5 * * * * /root/scripts/run.sh /path/to/real/script
>>
>> and keep a local copy of `/root/scripts/run.sh' on each node, which
>> contains something like:
>>
>> #!/bin/sh
>>
>> if test ! -x $1 ; then
>> exit 0
>> fi
>>
>> shift
>> exec $1 "$@"
>>
>> But that sounds like a bit of overkill, and you still get to keep a
>> local copy of `run.sh' on each node :-/
>
> Might as well just do that in the crontab:
>
> 0 0 * * * [ -x /path/to/script ] && /path/to/script

Indeed, but depending on the `/bin/sh' implementation, the return status
of the first part the return code may still be non-zero. That's what I
was trying to avoid by:

if test ! -x $1 ; then
exit 0
fi

Giorgos Keramidas wrote:
> On Tue, 09 Oct 2007 00:21:22 GMT, ddunham@taos.com (Darren Dunham) wrote:
>> Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
>>> You could always use something like:
>>>
>>> 5 * * * * /root/scripts/run.sh /path/to/real/script
>>>
>>> and keep a local copy of `/root/scripts/run.sh' on each node, which
>>> contains something like:
>>>
>>> #!/bin/sh
>>>
>>> if test ! -x $1 ; then
>>> exit 0
>>> fi
>>>
>>> shift
>>> exec $1 "$@"
>>>
>>> But that sounds like a bit of overkill, and you still get to keep a
>>> local copy of `run.sh' on each node :-/
>> Might as well just do that in the crontab:
>>
>> 0 0 * * * [ -x /path/to/script ] && /path/to/script
>
> Indeed, but depending on the `/bin/sh' implementation, the return status
> of the first part the return code may still be non-zero. That's what I
> was trying to avoid by:
>
> if test ! -x $1 ; then
> exit 0
> fi
>

That's why my shell coding paradigm is to always prefer the following
syntax:

[ ! -x /path/to/script ] || /path/to/script

even though it's a little less clear to novices, it always leaves $? in
the correct state. This in turn allows you to run scripts in "set -e"
mode or with a trap on error, depending on shell flavor, resulting in
more robust tools.

HT

<pbeckhelm@gmail.com> wrote in message
news:1191885166.257268.200940@19g2000hsx.googlegro ups.com...
> Greetings all,
>
> I'm wondering if anyone has found a more elegant way of solving this
> problem.
>
> The situation:
>
> I have two hosts that are SAN attached, but only the active (VxVM)
> node can actually mount the filesystems on the SAN. I have a user on
> both systems that needs to run a script via cron periodically and I
> want to make sure the scripts that that user is running are the exact
> same scripts.
>
> My solution:
>
> I have put the scripts on the SAN storage, and since only the active
> node can "see" the scripts, only the cron jobs on that node will
> succeed. My testing shows that the only ill effect thus far is a
> "rc=1" entry for that job in the /var/cron/log on the passive node.
>
> --
>
> I'd like to be sure that I'm doing this as elegantly and as
> efficiently as possible and not opening myself up to some kind of
> problem in so doing. Anyone have any ideas on how to do this better?
>
> Cheers,
>
> pb
>

Your solution is mine too in just this situation, no ill affects on the
results, but some of the others
who responded have some neat ideas. I will study them and use if possible.

On Oct 8, 5:21 pm, ddun...@taos.com (Darren Dunham) wrote:
>
> Might as well just do that in the crontab:
>
> 0 0 * * * [ -x /path/to/script ] && /path/to/script
>
> --
> Darren Dunham ddun...@taos.com
> Senior Technical Consultant TAOS http://www.taos.com/
> Got some Dr Pepper? San Francisco, CA bay area
> < This line left intentionally blank to confuse you.

I'm thinking that this is the most elegant way to do this, if for no
reason other than to make it explicitly clear to the reader that this
check is being done. In the way I'm currently doing it, we're relying
on cron to do this check, and I'd rather not do that (partly because I
don't want to try and predict how cron will react when something
breaks).

Can anyone see any problem with having cron do this checking?

pb

pbeckhelm@gmail.com wrote:
> On Oct 8, 5:21 pm, ddun...@taos.com (Darren Dunham) wrote:
>> Might as well just do that in the crontab:
>>
>> 0 0 * * * [ -x /path/to/script ] && /path/to/script
>>
>> --
>> Darren Dunham ddun...@taos.com
>> Senior Technical Consultant TAOS http://www.taos.com/
>> Got some Dr Pepper? San Francisco, CA bay area
>> < This line left intentionally blank to confuse you.
>
> I'm thinking that this is the most elegant way to do this, if for no
> reason other than to make it explicitly clear to the reader that this
> check is being done. In the way I'm currently doing it, we're relying
> on cron to do this check, and I'd rather not do that (partly because I
> don't want to try and predict how cron will react when something
> breaks).
>
> Can anyone see any problem with having cron do this checking?

There's no problem with cron doing the checking but I think you're
missing the point I made above. This:

0 0 * * * [ ! -x /path/to/script ] || /path/to/script

is more elegant, or at least better, than:

0 0 * * * [ -x /path/to/script ] && /path/to/script

Because the && formulation returns an error condition in the case that
the path doesn't exist. If you wanted that error condition you could
have just blindly done the exec in the first place, which is where we
came in.

HT

On Oct 10, 10:56 am, Henry Townsend <henry.towns...@not.here> wrote:
> pbeckh...@gmail.com wrote:
> > On Oct 8, 5:21 pm, ddun...@taos.com (Darren Dunham) wrote:
> >> Might as well just do that in the crontab:
>
> >> 0 0 * * * [ -x /path/to/script ] && /path/to/script
>
> >> --
> >> Darren Dunham ddun...@taos.com
> >> Senior Technical Consultant TAOS http://www.taos.com/
> >> Got some Dr Pepper? San Francisco, CA bay area
> >> < This line left intentionally blank to confuse you.
>
> > I'm thinking that this is the most elegant way to do this, if for no
> > reason other than to make it explicitly clear to the reader that this
> > check is being done. In the way I'm currently doing it, we're relying
> > on cron to do this check, and I'd rather not do that (partly because I
> > don't want to try and predict how cron will react when something
> > breaks).
>
> > Can anyone see any problem with having cron do this checking?
>
> There's no problem with cron doing the checking but I think you're
> missing the point I made above. This:
>
> 0 0 * * * [ ! -x /path/to/script ] || /path/to/script
>
> is more elegant, or at least better, than:
>
> 0 0 * * * [ -x /path/to/script ] && /path/to/script
>
> Because the && formulation returns an error condition in the case that
> the path doesn't exist. If you wanted that error condition you could
> have just blindly done the exec in the first place, which is where we
> came in.
>
> HT

You're absolutely right. I think the preservation of the error code
is the right practice.

pb

On Tue, 09 Oct 2007 12:15:39 -0400, Henry Townsend <henry.townsend@not.here> wrote:
>Giorgos Keramidas wrote:
>>> Might as well just do that in the crontab:
>>>
>>> 0 0 * * * [ -x /path/to/script ] && /path/to/script
>>
>> Indeed, but depending on the `/bin/sh' implementation, the return status
>> of the first part the return code may still be non-zero. That's what I
>> was trying to avoid by:
>>
>> if test ! -x $1 ; then
>> exit 0
>> fi
>>
>
> That's why my shell coding paradigm is to always prefer the following
> syntax:
>
> [ ! -x /path/to/script ] || /path/to/script
>
> even though it's a little less clear to novices, it always leaves $? in
> the correct state. This in turn allows you to run scripts in "set -e"
> mode or with a trap on error, depending on shell flavor, resulting in
> more robust tools.

Oh, heh! Neat trick, thanks :-)