Nut upsdev - May 2009 - [nut-commits] svn commit r1837 - trunk/clients

oops, this wasn't supposed to make it into the trunk yet. I can revert
it until further testing, but has anyone else tried running with this
patch?

http://lists.alioth.debian.org/pipermail/nut-upsdev/2009-April/003821.html

On Mon, May 4, 2009 at 10:05 PM, Charles Lepple
<clepple-guest at alioth.debian.org> wrote:
> Author: clepple-guest
> Date: Tue May  5 02:05:09 2009
> New Revision: 1837
>
> Log:
> upslog patch for PID basename
>
> Modified:
>   trunk/clients/upslog.c
>
> Modified: trunk/clients/upslog.c
>
=============================================================================>
--- trunk/clients/upslog.c      Tue May  5 01:32:47 2009        (r1836)
> +++ trunk/clients/upslog.c      Tue May  5 02:05:09 2009        (r1837)
> @@ -109,6 +109,7 @@
>        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("  -p <pidbase>  - Base name for PID file
(defaults to \"upslog\")\n");
>        printf("  -s <ups>      - Monitor UPS <ups> -
<upsname>@<host>[:<port>]\n");
>        printf("                - Example: -s myups at server\n");
>        printf("  -u <user>     - Switch to <user> if
started as root\n");
> @@ -372,6 +373,7 @@
>        time_t  now, nextpoll = 0;
>        const   char    *user = NULL;
>        struct  passwd  *new_uid = NULL;
> +       const   char    *pidfilebase = "upslog";
>
>        logformat = DEFAULT_LOGFORMAT;
>        user = RUN_AS_USER;
> @@ -380,7 +382,7 @@
>
>        prog = argv[0];
>
> -       while ((i = getopt(argc, argv, "+hs:l:i:f:u:V")) != -1) {
> +        while ((i = getopt(argc, argv, "+hs:l:i:f:u:Vp:")) !=
-1) {
>                switch(i) {
>                        case 'h':
>                                help(prog);
> @@ -408,6 +410,10 @@
>
>                        case 'V':
>                                exit(EXIT_SUCCESS);
> +
> +                       case 'p':
> +                               pidfilebase = optarg;
> +                               break;
>                }
>        }
>
> @@ -477,7 +483,7 @@
>
>        setup_signals();
>
> -       writepid("upslog");
> +       writepid(pidfilebase);
>
>        become_user(new_uid);
>
>
> _______________________________________________
> nut-commits mailing list
> nut-commits at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-commits
>


-- 
- Charles Lepple

On Tue, 5 May 2009, Charles Lepple wrote:
> oops, this wasn't supposed to make it into the trunk yet. I can
> revert it until further testing, but has anyone else tried running
> with this patch?
>
> http://lists.alioth.debian.org/pipermail/nut-upsdev/2009-April/003821
>.html
me ;)

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20090505/8168ebd7/attachment.pgp>

Citeren Daniel O'Connor <doconnor op 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

Citeren Daniel O'Connor <doconnor op 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