[Nut-upsdev] Spurious messages on start

[Arjen de Korte]

>> > I finally understand what the DUMPALL command does. I agree with your
>> > proposal. It's fine for upsmon sit there and watch the variable list
>> > slowly get populated, as long as ups.status is present.
>> I committed this change to the trunk. Do you think we should change the
>> behaviour of the DUMPALL command in the drivers, to make sure ups.status
>> is the first that is sent? Otherwise (in case of newhidups for instance)
>> we might be dumping lots of (irrelevant) data before ups.status is
>> finally
>> updated. Or would it be better to just ask for ups.status first and then
>> perform a DUMPALL, so that the order in which the data arrives is no
>> longer relevant? The first could be accomplished rather easily by
>> putting
>> ups.status in the root of the tree and changing the order how the tree
>> is
>> being walked through. Which by the way is a nice side effect of setting
>> ups.status to "WAIT" after clearing the tree in the server, it will
>> always
>> be in the root.
> that seems to suit me too.

Hmmm, aparently we don't have a GET command looking at dstate.c, so
explicitly asking for the variable "ups.status" is not an option. We have
to rely on the driver to send it somehow. I have some ideas on how to
accomplish that, so I'll work on that.

> note that my prev proposition to ensure the driver has really detected
> the UPS was simply to rely upon upsdrv_init*, so not calling the
> initial upsdrv_update.

For many drivers, that may be an option, but unfortunately, that's not
going to help a lot in speeding up startup of upsd. It seems that
currently the only way for upsd to get "ups.status" from the driver is to
request a DUMPALL. In the present setup, this means that all variables
supported by the driver will be spit out in alphabetical order, so
"ups.status" will probably not be the first one we receive.

> This allows both to speed up the process while ensuring there is
> really a device out there. The other way of enforcing the initial
> update with only feeding the status would also be a solution (but need
> some tests).

The patch I committed will speed up starting upsd significantly, with the
drawback that upsmon will only show the real ups.status once it has been
sent by the driver (which may take a while, see above). In the mean time
it will just sit and wait, but at least without nasty timeouts and/or
messages that the connection was lost.

> All the above is driver side, not server side as Arjen's proposition,
> and more intrusive too.

Not neccessarily more intrusive. If we put the "ups.status" in the
dtree_root and modify the st_tree_dump_conn() command so that it will
first send the contents of the current node (instead of resursively
descending to the left leaf node first), we might pull this off rather
quickly, by (again) adding a placeholder "ups.status" before populating
the other variables in the tree.

Or are we talking about two very different issues here?

Regards, Arjen