That is strange. I was under the impression that the port value is ignored (when using newhidups), and that specifying it should not break anything. Can specifying a wrong device actually break the socket naming scheme? Or was the problem here that the user changed the configuration file without restarting the driver, effectively causing a driver mismatch? Perhaps it should be documented. -- Peter
Gregory Gulik wrote: > > In my case the problem was that I was specifying a device of > /dev/hiddev0 which I was later informed isn't needed. That was causing > upsd to add hiddev0 to the filename of the socket it was looking for. > > > Arnaud Quette wrote: > > >there might be 2 things: > >- the Changes to 'upsdrvctl' Arjen has made not long ago, > >- the volatile /var directory I've seen on Debian (don't know for other). > >For this one, check my last post about "Problems starting upsd with > >newhidups". > > > >While the former still has to be backported (for 2.0.4, @Charles: can > >you take care of it?), the latter has to be addressed on a per system > >basis. > > > >Arnaud > >-- > >Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt > >Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ > >Debian Developer - http://people.debian.org/~aquette/ > >OpenSource Developer - http://arnaud.quette.free.fr/ > > > > > > -- > Greg Gulik http://www.gulik.org/greg/ > greg @ gulik.org > > > > _______________________________________________ > Nut-upsuser mailing list > [email protected] > http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser > _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
