[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010207: ldmfail problem (cont.)

>From:  Anne Wilson <address@hidden>
>Organization:  UCAR/UPC
>Keywords:  200102080012.f180CML11708 LDM ldmfail cron

Anne and Jennie,

>I think I have fixed the ldmfail problem on windfall.  The problem was
>that when run from cron the ldmfail perl script was not picking up the
>path properly.  I tried a few things, but the cleanest was to write a
>dinky script called ldmfailWrapper that I placed in the util directory. 
>The script simply sets the path variable, exports it, and calls ldmfail.

Good work.  I thought of another, perhaps simpler way of attacking this:

o change the ldmd.conf line:

  exec "xcd_run MONITOR"

  to

  exec "decoders/xcd_run MONITOR"

  (replace decoders/xcd_run with whatever directory xcd_run is in)

o change every decoder entry in pqact.conf to not rely on PATH to
  find the decoder.  For example, change:

  pnga2area

  to:

  decoders/pnga2area

  etc.

o change the xcd_run entries in pqact.conf to not rely on PATH as in
  the example above.

When ldmfail runs, we can guarantee that the current working directory
is ~ldm.  Give this, locating any/all decoders/programs/scripts with
relative pathnames (e.g., decoders/pnga2area, etc.) will work without
fail.

The nice thing about this approach is that one only has to make the
modifications once in pqact.conf.  You do, however, have to modify
each ldmd.xxx file to update the 'exec "xcd_run MONITOR"' entry.

>Jennie, this means you will be able to upgrade in a straightforward
>manner, since the installation doesn't change anything in the util
>directory.  But, if you want to change your failover site you will need
>to change this script.

This is the only drawback with the script approach.

>Tom, I tried several things from within cron.  The closest I could get
>was to give this command to cron:
>
>(. .profile ; bin/ldmfail -p <primaryHost> -f <failoverHost>)
>
>This would work - the path was available to ldmfail.  The problem was
>that  sh would complain about the ksh components of .profile and also
>about stty being undefined.  I could always dump the complaints to
>/dev/null, but it was just, well, unsatisfying.

I agree.

>There is another alternative, that looks something like this:
>
>(PATH=/usr/local/ldm/bin:/usr/local/bin bin/ldmfail -p <primaryHost> -f
><failoverHost>)
>
>which could make for an ugly, hairy line in crontab.  

Right.  I wouldn't like to have to look at this when crontab diving,
so I'm sure that Jennie wouldn't either.

>So, I don't know if this is the final solution for this problem or not. 
>There are a few alternatives for changing the distribution to handle
>this problem.  I think ideally the installation would set the path in
>ldmfail, like it does in ldmadmin.  I'll just put this on my toDo list
>(and watch it slowly sink below the other items).  No really, if you
>think this is a high priority item let's talk about it.

Perhaps what I outlined above is the path of least resistence.  Comments?

>Jennie, I think things should be working now.  Please let me know if you
>see any other problems.

>Best wishes to you and Gary.

Ditto!

Tom
--
+-----------------------------------------------------------------------------+
* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*
+-----------------------------------------------------------------------------+