-
-
Notifications
You must be signed in to change notification settings - Fork 424
Check if NUT clients always honour the connection timeout #3380
Copy link
Copy link
Open
Labels
CIEntries related to continuous integration infrastructure (here CI = tools + scripts + recipes)Entries related to continuous integration infrastructure (here CI = tools + scripts + recipes)Connection stability issuesIssues about driver<->device and/or networked connections (upsd<->upsmon...) going AWOL over timeIssues about driver<->device and/or networked connections (upsd<->upsmon...) going AWOL over timeportabilityWe want NUT to build and run everywhere possibleWe want NUT to build and run everywhere possible
Milestone
Description
Metadata
Metadata
Assignees
Labels
CIEntries related to continuous integration infrastructure (here CI = tools + scripts + recipes)Entries related to continuous integration infrastructure (here CI = tools + scripts + recipes)Connection stability issuesIssues about driver<->device and/or networked connections (upsd<->upsmon...) going AWOL over timeIssues about driver<->device and/or networked connections (upsd<->upsmon...) going AWOL over timeportabilityWe want NUT to build and run everywhere possibleWe want NUT to build and run everywhere possible
Experiments with recent PRs (adding NIT support to spawn a swarm of NUT clients/drivers and so stress the
upsdconnection handling ability and perhaps starve some clients of its attention) suggested that calls likeNUT_DEBUG_LEVEL=6 upsc -W 60 -l localhost:$NUT_PORTdo not always take 60 seconds to give up - there is a chance that they still abort after 5 or so seconds (default timeout).Investigate more; might be or not be related to #3775 and some run-time mis-linking (several in-memory symbols accessed randomly)?