Hey Dave, > > # ipmi-sensors -E -h ipmi008 > > hostlist_ranged_string: truncation
This ended up just being a dumb corner case if the -E option eliminated every node specified on the command line. I made a fix, and it'll go out in 0.8.2. I can't believe that bug lasted this long :-) As for your core problem: > # ipmi-sensors -E -h ipmi00[7,8] > > ipmi007: ID | Name | Type | Reading | > > Units | Event > > [this output left intentionally blank] > > ipmi007: 2592 | Watchdog | Watchdog 2 | N/A | > > N/A | N/A > > ipmi008: ipmi-sensors: connection timeout The maintainer of the hostlist library thinks there may be a bug in his code. If you specify: ipmi[007-008] instead of ipmi00[7-8] it will work for the time being. The issue is that when you specify "ipmi00[7-8]" the internal library recognizes "ipmi00" as the prefix of the range of nodes. However, when you input "ipmi007" or "ipmi008" (which if what you likely input when you configured ipmidetectd), it built up "ipmi" as the prefix of the range of nodes, and thus internally it is not finding/deleting/adding things consistently. Al On Mon, 2009-12-14 at 11:08 -0800, Al Chu wrote: > Hey Dave, > > I've been able to reproduce w/ your example of: > > > # ipmi-sensors -E -h ipmi008 > > hostlist_ranged_string: truncation > > So something is definitely amiss. I'm wondering if it's some strange > corner case in the hostlist parsing library. I'll take a look into it. > > Al > > On Mon, 2009-12-14 at 16:57 +0000, Dave Love wrote: > > I'd be interested in suggestions to debug this as I don't have much time > > to spend on it, and maybe there's something obvious to look at. (This > > is with version 0.8.1 and earlier versions.) > > > > I've got a couple of nodes that are out of service, but my out-of-band > > monitoring times out trying to access them: > > > > # ipmi-sensors -E -h ipmi00[7,8] > > ipmi007: ID | Name | Type | Reading | > > Units | Event > > [this output left intentionally blank] > > ipmi007: 2592 | Watchdog | Watchdog 2 | N/A | > > N/A | N/A > > ipmi008: ipmi-sensors: connection timeout > > > > This is despite ipmidetect knowing about the node (ipmi008) that timed > > out (where it's 8 and 9 that are missing, and 59 has a network issue): > > > > # ipmidetect > > detected: 104: ipmi[000-007,010-058,060-104],ipmilv3,ipmilv3fn > > undetected: 3: ipmi[008-009,059] > > > > I now wonder if it's related to what looks like a bug which I only just > > noticed while concocting an example to send: > > > > # ipmi-sensors -E -h ipmi008 > > hostlist_ranged_string: truncation > > > > > > _______________________________________________ > > Freeipmi-users mailing list > > [email protected] > > http://**lists.gnu.org/mailman/listinfo/freeipmi-users > > -- Albert Chu [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/freeipmi-users
