[Nut-upsdev] Spurious messages on start

[Arjen de Korte]

Peter Selinger wrote:

> I don't understand the issues that are involved in the start-up
> sequence very well. Could you summarize the current mechanism?

Currently, upsd connects to the driver(s), sends the DUMPALL command and
waits for it to complete (up to MAXINIT seconds). For some UPSes with a
large amount of data (or slow) to dump this may take a considerable amount
of time. During that time, upsmon will not be running as it should not be
started before upsd forks to the background. Monitoring will therefor not
be available for any UPS, not even for the ones that have already
completed the DUMPALL command. I don't think that is a good idea.

> From what I understand, the driver, upsd, and upsmon all fork to the
> background, but only after checking that they have started up without
> errors. The purpose is so that start-up scripts can check their return
> value and react to or report any errors as necessary.

This is good. Permissions problems for instance, or missing drivers can be
reported much better when we still have the console to write errors to.

> Wouldn't sending a fake INIT status shortcut the ability to detect any
> errors during driver startup?

Not really. We do check if the driver socket is available and readable.
This should cover most configuration problems. I'm not proposing to change
this, I just don't want to wait for the completion of the DUMPALL command.
If we can send data to the driver and the socket is readable, I'm fairly
confident that we can also receive the replies back, so there is no need
to wait for that.

> Perhaps the driver should stay in the foreground until it has read valid
> data from the UPS (with a timeout), so that upsd does not have to guess
> how long this will take?

This is the current situation. And while making the timeout (user)
configurable improves this a little, I think it would be much better to
background immediately after sending the DUMPALL command.

> But perhaps this would slow down startup too much. Perhaps it's
> sufficient to wait until *some* data has been read from the UPS. Is that
> what is currently happening?

Currently, the DUMPALL command must have completely finished for each
connected UPS. Therefor, if one driver is slow, it will delay all others too.

Yesterday evening I found that all that is needed is adding

	state_setinfo(&ups->inforoot, "ups.status", "INIT");

to (almost) the end of sstate_connect() and we're done. No more need for
MAXINIT (or initial_dump_wait() for that matter), the timeout for
communication with the driver will be handled by MAXAGE. Which is much
more intuitive for users as well, rather than having a separate timeout
parameter for startup.

I'll commit the patch to the trunk later today.

Best regards, Arjen