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>
On Fri, 27 May 2011, Keven L. Ates wrote:> 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.Under unix, at least, environment vars are copied to a process when it is created, and can only be changed by the process itself. So getenv() in effect *is* the global var/struct you want. Is Windows different in that regard? -- Stuart D. Gathman <stuart at bmsi.com> Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 "Confutatis maledictis, flammis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial.
Citeren "Keven L. Ates" <atescomp at gmail.com>:> Rewrite anyone?Just a quick question, do you have a clue what PID files are used for? Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected)
On Fri, 27 May 2011, Arjen de Korte wrote:> Just a quick question, do you have a clue what PID files are used for?Not sure if this is a rhetorical question, but PID files tell sysV init scripts what process id to signal when shutting down a service. There should be a "daemon" library that handles such details - and pid files are not necessary with more modern init systems such systemd. (Also, AIX has its own service manager that uses unix sockets to signal services. Portability requires an API.) -- Stuart D. Gathman <stuart at bmsi.com> Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 "Confutatis maledictis, flammis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial.
On Fri, May 27, 2011 at 2:20 PM, Stuart D. Gathman <stuart at bmsi.com> wrote:> On Fri, 27 May 2011, Keven L. Ates wrote: > > 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. >> > > Under unix, at least, environment vars are copied to a process when it is > created, and can only be changed by the process itself. So getenv() > in effect *is* the global var/struct you want. Is Windows different > in that regard? > > -- > Stuart D. Gathman <stuart at bmsi.com> > Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 > "Confutatis maledictis, flammis acribus addictis" - background song for > a Microsoft sponsored "Where do you want to go from here?" commercial. >That is generally the case, but then again people wish to do some odd things: http://stackoverflow.com/questions/205064/is-there-a-way-to-change-another-processs-environment-variables Keven -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110527/ed544035/attachment.html>
On Fri, May 27, 2011 at 4:33 PM, Stuart D. Gathman <stuart at bmsi.com> wrote:> On Fri, 27 May 2011, Arjen de Korte wrote: > > Just a quick question, do you have a clue what PID files are used for? >> > >Ditto on what Stuart said. They let various service managers "know" which PID is associated with which daemon so that it may successfully execute the start/stop/restart/status/... commands. Ex: sudo service nut status Checking status of Network UPS Tools * upsd is running * upsmon is running I suggested the change because I was replacing the Ubuntu dist of NUT with the development version and found that starting and stopping the service was not working properly. The NUT service "upsmon" was creating the PID file in one directory, but the service script was looking for it in another directory. I was able to set the environment variable for "statepath" and therefore "altpidpath" (but not perfectly, which led to a bug), but not for "pidpath". The other NUT service "upsd" was working just fine (but I'm not sure why..didn't trace that code). This just seemed a bit odd to me. Pursuing the configure.txt and common.c files, it looked like the related functions could use an overhaul for more than just my little issue. Keven -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110527/307b5367/attachment.html>
On Fri, May 27, 2011 at 2:20 PM, Stuart D. Gathman <stuart at bmsi.com> wrote:> On Fri, 27 May 2011, Keven L. Ates wrote: > > 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. >> > > Under unix, at least, environment vars are copied to a process when it is > created, and can only be changed by the process itself. So getenv() > in effect *is* the global var/struct you want. Is Windows different > in that regard? > > -- > Stuart D. Gathman <stuart at bmsi.com> > Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 > "Confutatis maledictis, flammis acribus addictis" - background song for > a Microsoft sponsored "Where do you want to go from here?" commercial. >That is generally the case, but then again people wish to do some odd things: http://stackoverflow.com/questions/205064/is-there-a-way-to-change-another-processs-environment-variables Keven -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110527/405de18e/attachment-0001.html>