[Nut-upsuser] NUT behaviour when master system fails

[Jon Clark]

Arjen,

Thank you very much for your reply.  I have looked at the logs of the 
recent changes submitted through SVN and found this one:

++++ Begin SVN log entry

Handle all communications with the server through 
upscli_sendline/readline and use of select() to prevent blocking on I/O 
calls when the server is not responding (while still allowing it a 
couple of seconds to reply).

The above fixes a bug with upsmon ignoring DEADTIME when the connection 
to the server is lost. Since we're using blocking I/O here, a read() 
from the server would stall upsmon. Since we can't change to 
non-blocking I/O (after writing a command to the server, the client 
immediately reads a reply), the only option left is to use select(). We 
do that now for all communication with the server.

++++ End SVN log entry

This describes our problem and an implemented solution (the solution 
that I would have suggested as well!).  My thanks go to all those who 
continue to improve the NUT software.

Regards,
Jon

Arjen de Korte wrote:
> [...]
>
>   
>> A brief examination of the NUT source code indicates that a system
>> "write" statement is being used to communicate across the network with
>> the upsd process of the master. We think that this system function
>> blocks by default. Maybe the default blocking settings are in use. We
>> don't know, this is probably very wide of the mark, but it is the best
>> we have come up with!
>>     
>
> If this is indeed the cause of the problem, you may wish to upgrade to the
> latest version from the SVN trunk. Just two days ago, a change to the
> upsclient library was made so that it no longer blocks on read/write
> actions.
>
> Best regards, Arjen
>   

-- 
----------------------------
Jon Clark
Scientific Officer
Dept. of Applied Mathematics
University of Sheffield
Sheffield, S3 7RH, UK
----------------------------