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

[Arjen de Korte]

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