[Nut-upsuser] Bogus "UPS not available" messages

[Arjen de Korte]

Eric S. Raymond wrote:

> Many repetitions of this message with different timestamps.
> 
> May 23 11:25:51 snark upsmon[26084]: Poll UPS [myups at snark] failed - Write error: Bad file descriptor
> May 23 11:25:56 snark upsd[26065]: Rejecting TCP connection from 192.168.1.11
> May 23 11:25:56 snark upsmon[26084]: Set username on [myups at snark] failed: Serve

This looks a lot like problems with setting the access controls or on
the upsd server. Could you post the contents of 'upsd.conf' and
'upsd.users' here or in a private message? This certainly has nothing to
do with the driver.

[...]

>>> I don't see this documented anywhere, and it should be.
>> This is documented in the INSTALL file (amongst other places by the
>> way), which serves as a starting point for new users.
> The INSTALL file refers to "the syslog", which is not good enough
> without at least a pointer to documentation (like a manual page) on
> where the syslog might be found on your system.

Where would we stop? Should we provide links to all system commands we
use? I don't think it is too much to ask that people know where to find
their syslog, certainly not if you're setting up a UPS on a server
(which seems to be the most popular application).

> (It should also give the facility code that nut uses for logging. because that affects 
> where the log messages end up.)

This is specified in docs/configure.txt which is generally only used by
people building packages. The average Joe User that doesn't roll his own
binaries probably never needs to know, since this will be set properly
by the person building it for his distribution. People building their
own packages will be smart enough to find the appropriate facility from
the options to configure themselves.

> Yes, I'm smart enough to figure this out on my own, but the
> documentation should be usable by somebody who is not an experienced
> Unix sysadmin.

If you're not an experienced Unix sysadmin, chances are that you're not
building your own packages either, but rather use whatever is available
for the distribution you're using.

> Remember, I'm not only trying to solve my own
> problem, I'm trying to smooth the way for other is the future.

I understand, but also note that we have other things to do as well,
besides educating people on where to find their syslog. In the time I'm
involved in NUT now, this has never been a problem, so it is not very
high on my list of priorities.

> (Often, this involves repeatedly kicking project devs to improve their
> documentation, or writing better documentation myself.  You may expect
> me to do both things a lot if I stick around here.)

Welcome aboard then, many parts of the documentation badly need updating.

>> This is logged in the syslog in case the status changes. It makes no
>> sense to store the timestamp for the last time data was received.
> Why not?  Seems natural to me to want to know the timestamp on the
> data sample I'm seeing.

Because the vast majority of people will never look at the syslog
entries NUT produces once they have successfully setup NUT. In contrast,
we even receive complaints that NUT is too verbose in some aspects and
clogging up syslog.

Regarding the timestamp, when data is stale it is unimportant how stale
it is, it should not be used anymore. Most of the relevant data is very
volatile (battery charge, mains state) and after expiration becomes
useless and should not be relied upon anymore.

Best regards, Arjen