[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