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

Daniel O'Connor doconnor at gsoft.com.au
Mon May 11 23:54:44 UTC 2009


On Tue, 12 May 2009, Arjen de Korte wrote:
> Citeren Daniel O'Connor <doconnor at 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
-------------- 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/20090512/260e9c96/attachment.pgp>


More information about the Nut-upsdev mailing list