I've written a script that will review a log file and produce some metrics.
I want the state of the script to be persistent across reboots. I'm leary
of using /tmp, /var/tmp, or $XYMONTMP (which on our install is /tmp)
because those locations are easy to hijack, and therefore not safe for
anything with a predictable name.
It sounds like, from the two responses I've gotten (thanks!), there is not
an explicitly appropriate location for my use, but that $XYMONTMP and/or
$XYMONCLIENTLOGS might be the best candidates, if just because they're the
only writable locations in the install.
Thanks!
--
*Steve Coile*Senior Network and Systems Engineer, McClatchy Interactive
<http://www.mcclatchyinteractive.com/>;
Office: XXX-XXX-XXXX | Mobile: XXX-XXX-XXXX | Fax: XXX-XXX-XXXX
On Tue, Sep 16, 2014 at 6:45 PM, J.C. Cleaver <user-87556346d4af@xymon.invalid>
wrote:
On Tue, September 16, 2014 11:45 am, Steve Coile wrote:
I've written a client extension script that wants to maintain state
between
runs, essentially to know where it left off after the last run. Where is
the "proper" place to keep such state files? On our install,
~xymon/client/tmp is a symlink to /tmp, which seems like a bad choice.
--
I think it really depends on your specific use-case, including how
"resilient" the test needs to be against local problems, and whether the
state needs to persist across a reboot. In addition, how it's been
packaged plays a role.
I tend to be a fan of client runtime-dependent files (such as the .msg
file the standard client builds) on tmpfs -- typically /dev/shm on Linux.
That ensures we can still report even if the silly Dell controller has
dropped us into read-only mode. OTOH, that's a bad place for keeping track
of a nightly-rotated-logfile state unless you're okay with losing state
after a crash or reboot (and potentially getting alerted again).
If it needs to be kept around, I'd suggest /var/tmp/ or /var/tmp/xymon/
(if present. If neither is writable or easily derived, $XYMONCLIENTLOGS
(potentially ~xymon/client/logs) is simple enough to use, and should be
basically reliable.
Regards,
-jc