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

[Daniel O'Connor]

On Fri, 15 May 2009, Arjen de Korte wrote:
> Citeren Daniel O'Connor <doconnor at gsoft.com.au>:
> >> 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.
> >
> > That seems broken anyway, either it expands forever and you run out
> > of space or you try and rotate it and upslog stops.
>
> If you log a few dozen bytes to the logs once every five minutes
> (which boils down to about 1 kB/hr), realistically this may never
> happen, so it is questionable that this is ever going to cause a
> problem.

<shrugs> depends on your /var.

If it WAS a small flash embedded system 60Mb a year would not be pocket 
change. We still have some systems in the field with 256Mb /var's that 
are >50% full.

> > IMO the SuSE package maintainer should change it to either run
> > upslog as root or make a new directory iun /var/log owned but the
> > NUT user..
>
> The SuSE package maintainer did the only sensible thing here and
> removed upslog from the default startup script and leave the
> configuration to the user. One shouldn't run upslog without a reason.

I guess so, but sensible defaults are a good idea.
(ie you shouldn't have to do more than enable it and pick the format to 
get it running).

-- 
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/20090515/6a33b6d2/attachment.pgp>