[Nut-upsdev] Environment Variables
Keven L. Ates
atescomp at gmail.com
Fri May 27 18:58:17 UTC 2011
I noticed that many configuration options (configure.txt) have environment
variable overrides. However, an important one does not. In the
configuration.txt file, there is one section:
Directories used by NUT at run-time
-----------------------------------
--with-pidpath=PATH
Changes the directory where pid files are stored. By default this is
/var/run. Certain programs like upsmon will leave files here.
--with-altpidpath=PATH
Programs that normally don't have root powers, like the drivers and
upsd, write their pid files here. By default this is whatever the
statepath is, as those programs should be able to write there.
--with-statepath=PATH
Change the default location of the state sockets created by the
drivers.
The NUT_STATEPATH environment variable overrides this at run time.
Default is /var/state/ups.
-----------------------------------
So, the PID path does not have an env var override, but the state path does
and it substitutes for the Alternate PID path as well.
I'm thinking the PID path should also have an override, like NUT_PIDPATH.
Maybe add a function in common.txt such as:
/* Return the path for pid files */
const char * pidpath(void)
{
const char * path;
if ((path = getenv("NUT_PIDPATH")) == NULL)
path = PIDPATH;
return path;
}
While using the NUT_STATEPATH, I noticed an error where in some areas
altpidpath was not using the statepath as advertised as an override, so I
include a "patch" here for altpidpath() in common.c:
/* Return the alternate path for pid files */
const char * altpidpath(void)
{
const char * path;
if ((path = getenv("NUT_STATEPATH")) == NULL)
path = ALTPIDPATH;
return path;
}
A problem I see with the above code is that the env checking function
appears to be called every time a variable is needed (see statepath calls).
This practice should probable be changed so that the env variable is loaded
once at program startup and stored in a global var/struct and then used as
needed. This is so that changes to a env var within the programs runtime
context does not modify behavior or cause error, such as changing where it
looks for the PID file AFTER the PID file was created.
Maybe each should have their own env vars: NUT_PIDPATH, NUT_ALTPIDPATH,
NUT_STATEPATH (and others). In general, each configuration variable
probably ought to have a there own environment variables. This would
facilitate fine control over the program within scripts, etc., for the
following reasons:
Since most control could be maintained by the service script or a
configuration file augmenting the service script,
1. environment variables makes the program very runtime manageable.
2. various distribution maintainers would not need to configure compile time
defaults to control the program, just manage a config file.
3. developers could quickly check variations by changing environment
variables instead of a recompile.
Rewrite anyone?
Thanks,
Keven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110527/1947d0b6/attachment-0001.html>
More information about the Nut-upsdev
mailing list