Hi Arjen,
I don't understand the issues that are involved in the start-up
sequence very well. Could you summarize the current mechanism?
>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.
Wouldn't sending a fake INIT status shortcut the ability to detect any
errors during driver startup? 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?
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?
Sorry if all of this sounds very confused. -- Peter
Arjen de Korte wrote:>
> I think I have found a way to deal with the issue of the spurious
> message on startup of NUT. Before implementing it, I would like to see
> what the other developers think of this idea.
>
> My proposal is not to wait for DUMPDONE in the startup of upsd for a
> duration of MAXINIT seconds, but rather to send the fake "INIT"
status
> in response to a ups.status request. As soon as DUMPDONE hits, or
> MAXINIT seconds since the start of upsd have elapsed, we report to this
> request as usual. By doing so, we avoid blocking the startup sequence
> (like we do now, for up to MAXINIT seconds), without upsmon complaining
> about lost communications (provided it doesn't choke on INIT, but this
> can be dealt with easily if needed).
>
> Fire at will.
>
> Regards, Arjen
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>