Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
2009/5/17 Daniel O'Connor docon...@gsoft.com.au
On Sun, 17 May 2009, Arnaud Quette wrote:
Sounds good to me.
I was also thinking of an option to use syslog, that way upslog can
run as whatever user and not have to worry about file perms.
can you propose a patch for that?
Well I have this..
diff -r c79ce7440a78 clients/upslog.c
--- a/clients/upslog.c Sun May 17 18:09:51 2009 +0930
+++ b/clients/upslog.c Sun May 17 19:28:15 2009 +0930
@@ -38,6 +38,9 @@
#include timehead.h
#include upslog.h
+#include syslog.h
+#include stdarg.h
+
static int port, reopen_flag = 0, exit_flag = 0;
static char*upsname, *hostname;
static UPSCONN_t ups;
@@ -55,6 +58,11 @@
static void reopen_log(void)
{
+ if (logfile == NULL) {
+ upslogx(LOG_INFO, logging to syslog);
+ return;
+ }
+
if (logfile == stdout) {
upslogx(LOG_INFO, logging to stdout);
return;
@@ -108,7 +116,7 @@
printf( -f format - Log format. See below for details.\n);
printf(- Use -f \format\ so your shell doesn't
break it up.\n);
printf( -i interval - Time between updates, in seconds\n);
- printf( -l logfile - Log file name, or - for stdout\n);
+ printf( -l logfile - Log file name (- for stdout, syslog for
syslog)\n);
printf( -s ups - Monitor UPS ups -
upsname@host[:port]\n);
printf(- Example: -s my...@server\n);
printf( -u user - Switch to user if started as root\n);
@@ -354,9 +362,12 @@
tmp = tmp-next;
}
- fprintf(logfile, %s\n, logbuffer);
- fflush(logfile);
-}
+ if (logfile == NULL)
+ syslog(LOG_INFO, %s, logbuffer);
+ else {
+ fprintf(logfile, %s\n, logbuffer);
+ fflush(logfile);
+ }
/* -s monhost
* -l log file
@@ -364,6 +375,7 @@
* -f format
* -u username
*/
+}
int main(int argc, char **argv)
{
@@ -458,21 +470,28 @@
fprintf(stderr, Warning: initial connect failed: %s\n,
upscli_strerror(ups));
- if (strcmp(logfn, -) == 0)
- logfile = stdout;
- else
- logfile = fopen(logfn, a);
-
- if (logfile == NULL)
- fatal_with_errno(EXIT_FAILURE, could not open logfile %s,
logfn);
-
+ if (strcmp(logfn, syslog)) {
+ openlog(upslog, LOG_PID, LOG_DAEMON);
+ logfile = NULL;
+ } else {
+ if (strcmp(logfn, -) == 0)
+ logfile = stdout;
+ else
+ logfile = fopen(logfn, a);
+
+ if (logfile == NULL)
+ fatal_with_errno(EXIT_FAILURE, could not open
logfile %s, logfn);
+ }
+
/* now drop root if we have it */
new_uid = get_user_pwent(user);
But I am having trouble debugging it because libtool is being a right pain
in the arse.
[cain 19:28] ~/projects/nut-2.4.1 gdb ./clients/.libs/upslog
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
(gdb) run
Starting program:
/usr/local/Genesis/home/doconnor/projects/nut-2.4.1/clients/.libs/upslog
/libexec/ld-elf.so.1: Shared object libupsclient.so.1 not found, required
by upslog
Program exited with code 01.
(gdb) %
[cain
19:29] ~/projects/nut-2.4.1 libtool --mode=execute gdb clients/upslog
clients/upslog: Xclients/upslog: not found
clients/upslog: /usr/local/bin/libtool: error:
`/usr/local/Genesis/home/doconnor/projects/nut-2.4.1/.libs/upslog' does
not exist: not found
This script is just a wrapper for upslog.: not found
See the libtool documentation for more information.
I can't just install it because this is on a production system.
adding /usr/local/Genesis/home/doconnor/projects/nut-2.4.1/.libs/ to
$LD_LIBRARY_PATH might help you there.
Also, either my changes broke it or it's already busted, but -l - doesn't
keep it in the foreground..
still working in a vanilla trunk.
I've not tried your patch (failing to apply, and not much time to apply by
hand), but it seems fine apart of:
+ if (strcmp(logfn, syslog)) {
which I guess should be
+ if (strcmp(logfn, syslog) == 0) {
btw, use the unified format for diffing (ie diff -ru ...).
Arnaud
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
hi Daniel, 2009/5/16 Daniel O'Connor docon...@gsoft.com.au On Sat, 16 May 2009, Arnaud Quette wrote: guys, you seem to be standing on your position, each one with valid points. how about adding another option to close this log? that way, you satisfy both needs without breaking the existing behavior by default... Sounds good to me. I was also thinking of an option to use syslog, that way upslog can run as whatever user and not have to worry about file perms. can you propose a patch for that? Arnaud ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
On Sun, 17 May 2009, Arnaud Quette wrote:
Sounds good to me.
I was also thinking of an option to use syslog, that way upslog can
run as whatever user and not have to worry about file perms.
can you propose a patch for that?
Well I have this..
diff -r c79ce7440a78 clients/upslog.c
--- a/clients/upslog.c Sun May 17 18:09:51 2009 +0930
+++ b/clients/upslog.c Sun May 17 19:28:15 2009 +0930
@@ -38,6 +38,9 @@
#include timehead.h
#include upslog.h
+#include syslog.h
+#include stdarg.h
+
static int port, reopen_flag = 0, exit_flag = 0;
static char*upsname, *hostname;
static UPSCONN_t ups;
@@ -55,6 +58,11 @@
static void reopen_log(void)
{
+ if (logfile == NULL) {
+ upslogx(LOG_INFO, logging to syslog);
+ return;
+ }
+
if (logfile == stdout) {
upslogx(LOG_INFO, logging to stdout);
return;
@@ -108,7 +116,7 @@
printf( -f format - Log format. See below for details.\n);
printf(- Use -f \format\ so your shell doesn't
break it up.\n);
printf( -i interval - Time between updates, in seconds\n);
- printf( -l logfile - Log file name, or - for stdout\n);
+ printf( -l logfile - Log file name (- for stdout, syslog for
syslog)\n);
printf( -s ups - Monitor UPS ups -
upsname@host[:port]\n);
printf(- Example: -s my...@server\n);
printf( -u user - Switch to user if started as root\n);
@@ -354,9 +362,12 @@
tmp = tmp-next;
}
- fprintf(logfile, %s\n, logbuffer);
- fflush(logfile);
-}
+ if (logfile == NULL)
+ syslog(LOG_INFO, %s, logbuffer);
+ else {
+ fprintf(logfile, %s\n, logbuffer);
+ fflush(logfile);
+ }
/* -s monhost
* -l log file
@@ -364,6 +375,7 @@
* -f format
* -u username
*/
+}
int main(int argc, char **argv)
{
@@ -458,21 +470,28 @@
fprintf(stderr, Warning: initial connect failed: %s\n,
upscli_strerror(ups));
- if (strcmp(logfn, -) == 0)
- logfile = stdout;
- else
- logfile = fopen(logfn, a);
-
- if (logfile == NULL)
- fatal_with_errno(EXIT_FAILURE, could not open logfile %s,
logfn);
-
+ if (strcmp(logfn, syslog)) {
+ openlog(upslog, LOG_PID, LOG_DAEMON);
+ logfile = NULL;
+ } else {
+ if (strcmp(logfn, -) == 0)
+ logfile = stdout;
+ else
+ logfile = fopen(logfn, a);
+
+ if (logfile == NULL)
+ fatal_with_errno(EXIT_FAILURE, could not open logfile
%s, logfn);
+ }
+
/* now drop root if we have it */
new_uid = get_user_pwent(user);
But I am having trouble debugging it because libtool is being a right pain in
the arse.
[cain 19:28] ~/projects/nut-2.4.1 gdb ./clients/.libs/upslog
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
(gdb) run
Starting program:
/usr/local/Genesis/home/doconnor/projects/nut-2.4.1/clients/.libs/upslog
/libexec/ld-elf.so.1: Shared object libupsclient.so.1 not found, required by
upslog
Program exited with code 01.
(gdb) %
[cain
19:29] ~/projects/nut-2.4.1 libtool --mode=execute gdb clients/upslog
clients/upslog: Xclients/upslog: not found
clients/upslog: /usr/local/bin/libtool: error:
`/usr/local/Genesis/home/doconnor/projects/nut-2.4.1/.libs/upslog' does
not exist: not found
This script is just a wrapper for upslog.: not found
See the libtool documentation for more information.
I can't just install it because this is on a production system.
Also, either my changes broke it or it's already busted, but -l - doesn't
keep it in the foreground..
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
signature.asc
Description: This is a digitally signed message part.
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
Citeren Daniel O'Connor docon...@gsoft.com.au: Well, one thing is that it *will* cause existing installations to break, where upslog is started as 'root' and the NUT user doesn't have write permissions to the log file. Obviously, send upslog a SIGHUP in such case would effectively kill it (because it can't reopen the log), but I know of at least one distribution (SuSE) that had a default setup exactly like that. We've seen people complain about this behavior before, so in all likelihood, it is being used in the field. That seems broken anyway, either it expands forever and you run out of space or you try and rotate it and upslog stops. If you log a few dozen bytes to the logs once every five minutes (which boils down to about 1 kB/hr), realistically this may never happen, so it is questionable that this is ever going to cause a problem. IMO the SuSE package maintainer should change it to either run upslog as root or make a new directory iun /var/log owned but the NUT user.. The SuSE package maintainer did the only sensible thing here and removed upslog from the default startup script and leave the configuration to the user. One shouldn't run upslog without a reason. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
On Fri, 15 May 2009, Arjen de Korte wrote: Citeren Daniel O'Connor docon...@gsoft.com.au: Well, one thing is that it *will* cause existing installations to break, where upslog is started as 'root' and the NUT user doesn't have write permissions to the log file. Obviously, send upslog a SIGHUP in such case would effectively kill it (because it can't reopen the log), but I know of at least one distribution (SuSE) that had a default setup exactly like that. We've seen people complain about this behavior before, so in all likelihood, it is being used in the field. That seems broken anyway, either it expands forever and you run out of space or you try and rotate it and upslog stops. If you log a few dozen bytes to the logs once every five minutes (which boils down to about 1 kB/hr), realistically this may never happen, so it is questionable that this is ever going to cause a problem. shrugs depends on your /var. If it WAS a small flash embedded system 60Mb a year would not be pocket change. We still have some systems in the field with 256Mb /var's that are 50% full. IMO the SuSE package maintainer should change it to either run upslog as root or make a new directory iun /var/log owned but the NUT user.. The SuSE package maintainer did the only sensible thing here and removed upslog from the default startup script and leave the configuration to the user. One shouldn't run upslog without a reason. I guess so, but sensible defaults are a good idea. (ie you shouldn't have to do more than enable it and pick the format to get it running). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
Citeren Daniel O'Connor docon...@gsoft.com.au: Obviously I can't prove a negative, but I find it extremely unlikely it could possibly be an issue on ANY platform, embedded or otherwise. Well, one thing is that it *will* cause existing installations to break, where upslog is started as 'root' and the NUT user doesn't have write permissions to the log file. Obviously, send upslog a SIGHUP in such case would effectively kill it (because it can't reopen the log), but I know of at least one distribution (SuSE) that had a default setup exactly like that. We've seen people complain about this behavior before, so in all likelihood, it is being used in the field. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
On Thu, 14 May 2009, Arjen de Korte wrote: Citeren Daniel O'Connor docon...@gsoft.com.au: Obviously I can't prove a negative, but I find it extremely unlikely it could possibly be an issue on ANY platform, embedded or otherwise. Well, one thing is that it *will* cause existing installations to break, where upslog is started as 'root' and the NUT user doesn't have write permissions to the log file. Obviously, send upslog a SIGHUP in such case would effectively kill it (because it can't reopen the log), but I know of at least one distribution (SuSE) that had a default setup exactly like that. We've seen people complain about this behavior before, so in all likelihood, it is being used in the field. That seems broken anyway, either it expands forever and you run out of space or you try and rotate it and upslog stops. IMO the SuSE package maintainer should change it to either run upslog as root or make a new directory in /var/log owned but the NUT user.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
On Wed, 13 May 2009, Arjen de Korte wrote: Citeren Daniel O'Connor docon...@gsoft.com.au: Even over NFS it would be trivial. If you have flash and you're worried about excess writes it won't make a difference. How can you be so sure? NUT runs on many different configurations and platforms. Obviously I can't prove a negative, but I find it extremely unlikely it could possibly be an issue on ANY platform, embedded or otherwise. I think it's more likely someone will log 1 UPS than they would have an issue with an extra open/close every 5 minutes. I honestly don't know. That's why I prefer to keep things as they are, unless there is something really broken in the current implementation. As far as I can see, there isn't (at least not in this aspect). It is broken if you have more than one UPS logged because you only get one PID file for both upslog processes. This is an annoying problem - the file doesn't get re-opened so the system will run out of disk space on /var eventually. This is a concrete problem that happens right now, I think re-opening the files is worth doing to fix it versus not doing it because there may be some system that has an issue with this (that no one has an example of yet). risk of breaking existing installations that may rely on upslog keeping the logfile open. The current design is broken since it won't allow you to have more than one upslog running. Use the '-p' option that was recently added. You can have as many upslog instances running as you please and still be able to single them out. Yes, I submitted the patch for that. There is still the pitfall where you have to remember to use the option if you use upslog twice though. I think that, truly, doing an open/close for each write is by far the simplest way to solve the problem and there is no downside. There is, besides the chance that we might have overlooked a pitfall. You'd still need to be able to uniquely identify the various instances of upslog running, in order to be able to shut them down separately. So the recently added '-p' argument is needed anyway, so we might just as well use the same mechanism to send upslog a SIGHUP should we decide to rotate the log. I'm not saying do the open/close instead of -p, I think it should do both. I can't envisage any scenario where an open/close each log would cause a problem. I can't envisage any way how to guarantee it won't cause a problem. That's my point (besides the downside of having a backgrounded process open/close the log file periodically, which has drawbacks when it comes to error reporting). It's impossible to prove a negative :) Well, if the current set of code runs out of disk space it will have exactly the same problem, in that cause I believe it just exits (sensible IMO). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
Citeren Daniel O'Connor docon...@gsoft.com.au: Even over NFS it would be trivial. If you have flash and you're worried about excess writes it won't make a difference. How can you be so sure? NUT runs on many different configurations and platforms. I think it's more likely someone will log 1 UPS than they would have an issue with an extra open/close every 5 minutes. I honestly don't know. That's why I prefer to keep things as they are, unless there is something really broken in the current implementation. As far as I can see, there isn't (at least not in this aspect). I think sending upslog a SIGHUP to make it reopen the logs after rotating is too much of a burden anyhow and certainly not worth the I presume this should be .. not too much of a burden .. Yes. risk of breaking existing installations that may rely on upslog keeping the logfile open. The current design is broken since it won't allow you to have more than one upslog running. Use the '-p' option that was recently added. You can have as many upslog instances running as you please and still be able to single them out. I think that, truly, doing an open/close for each write is by far the simplest way to solve the problem and there is no downside. There is, besides the chance that we might have overlooked a pitfall. You'd still need to be able to uniquely identify the various instances of upslog running, in order to be able to shut them down separately. So the recently added '-p' argument is needed anyway, so we might just as well use the same mechanism to send upslog a SIGHUP should we decide to rotate the log. I can't envisage any scenario where an open/close each log would cause a problem. I can't envisage any way how to guarantee it won't cause a problem. That's my point (besides the downside of having a backgrounded process open/close the log file periodically, which has drawbacks when it comes to error reporting). Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
On Mon, 11 May 2009, Arjen de Korte wrote: Citeren Charles Lepple clep...@gmail.com: I think I would really prefer that upslog didn't keep the log file open, that way it doesn't matter if the log file is rotated. I'm starting to come around to this idea. For some reason, I thought the upslog program went into the background for a log file other than stdout, which would complicate error reporting, but that isn't the case. It *should* background if it isn't logging to stdout, so if it isn't, we might have a bug here. I'm not to keen on open/close for each line we log, for exactly the reason you mention here. Can you elaborate? I don't see any disadvantage to doing an open/close for each line. The extra syscall load would be trivial. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
On Tue, 12 May 2009, Arjen de Korte wrote: Citeren Daniel O'Connor docon...@gsoft.com.au: It *should* background if it isn't logging to stdout, so if it isn't, we might have a bug here. I'm not to keen on open/close for each line we log, for exactly the reason you mention here. Can you elaborate? Sure. I don't see any disadvantage to doing an open/close for each line. The extra syscall load would be trivial. This is probably true if you're logging to a file on a local hard disk, but I'm not so sure about *all* possible systems/devices people may be logging to. So therefor, unless there is a compelling reason to open/close the logfile for each line, I'd rather keep the behavior as it is. Even over NFS it would be trivial. If you have flash and you're worried about excess writes it won't make a difference. I think it's more likely someone will log 1 UPS than they would have an issue with an extra open/close every 5 minutes. I think sending upslog a SIGHUP to make it reopen the logs after rotating is too much of a burden anyhow and certainly not worth the I presume this should be .. not too much of a burden .. risk of breaking existing installations that may rely on upslog keeping the logfile open. The current design is broken since it won't allow you to have more than one upslog running. I think that, truly, doing an open/close for each write is by far the simplest way to solve the problem and there is no downside. I can't envisage any scenario where an open/close each log would cause a problem. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
Citeren Charles Lepple clep...@gmail.com: I think I would really prefer that upslog didn't keep the log file open, that way it doesn't matter if the log file is rotated. I'm starting to come around to this idea. For some reason, I thought the upslog program went into the background for a log file other than stdout, which would complicate error reporting, but that isn't the case. It *should* background if it isn't logging to stdout, so if it isn't, we might have a bug here. I'm not to keen on open/close for each line we log, for exactly the reason you mention here. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
On May 6, 2009, at 8:32 AM, Arnaud Quette wrote: what would you think about adding your patch (as an override option) but defaulting to upslog-ups-hostname (for example: upslog- myups-localhost). This would always satisfy the unique name, with a sane default naming, and give a pattern for the logrotate definition (btw, would be interesting to add a sample config somewhere in the tree). Constructing a new name could easily be done in whatever script starts upslog. ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
On May 6, 2009, at 11:23 PM, Daniel O'Connor wrote: I think I would really prefer that upslog didn't keep the log file open, that way it doesn't matter if the log file is rotated. I'm starting to come around to this idea. For some reason, I thought the upslog program went into the background for a log file other than stdout, which would complicate error reporting, but that isn't the case. I also can't envision a case where the data logging rate would make the extra open/close matter. We might want to keep the PID file around for stopping upslog programmatically. ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [nut-commits] svn commit r1837 - trunk/clients
On Thu, 7 May 2009, Charles Lepple wrote: On May 6, 2009, at 11:23 PM, Daniel O'Connor wrote: I think I would really prefer that upslog didn't keep the log file open, that way it doesn't matter if the log file is rotated. I'm starting to come around to this idea. For some reason, I thought the upslog program went into the background for a log file other than stdout, which would complicate error reporting, but that isn't the case. I also can't envision a case where the data logging rate would make the extra open/close matter. Agreed. We might want to keep the PID file around for stopping upslog programmatically. Yes. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
