Eric S. Raymond wrote: > Many repetitions of this message with different timestamps. > > May 23 11:25:51 snark upsmon[26084]: Poll UPS [EMAIL PROTECTED] 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 [EMAIL PROTECTED] > 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 _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
