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

[Daniel O'Connor]

On Wed, 13 May 2009, Arjen de Korte wrote:
> Citeren Daniel O'Connor <doconnor at 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
-------------- 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/20090514/d06220b9/attachment.pgp>