On Lift disconnect, pysensorproxy stops working

[jonashoechst]

ifup sometimes takes more than 15 seconds and thus is stopped. The semaphore used to access the lift is not freed, and leads to a non-working lift.

[jonashoechst]

The issue was addressed in 672bb668caeb6869fd9958a0e59b7f02fd674fbd, but seems to appear only in rare cases. Also with 3cc327938968519d249b966fabf70ca3615d2542 verbosity for ifup / ifdown is added, so it can be debugged better.

[gisma]

The following are all shots in the dark.... Nevertheless the permanent loosing of wlan connection is a major and well known problem (e.g. #19 #32) that is showing up as follows:

Observations:

• Regularly we are loosing up to 20 and more times (on 30m distance) the WiFi connections - no difference if 2 meters or 30 meters above ground. This forces the motor controller to stop which is a feature. However this will spoil our calibration process and hence measurements.
• Occasionally the motor controller stops while there is established still a WiFi connection. Why is the motor unit in this case stopping?
• Occasionally the WiFI connection is not re-established and the system is freezing. This stops our measurements. How can this Happen If the semaphore ist freed now?

Solutions up to now:

• Up to now we are just increasing the time period running the motor controller without established WiFi connection. That is definitely not a good idea...
• We also tried to identify and kill zombie threads.

However the problems are still remaining and the top act is the freezing system followed by an arbitrary calibration Task.

Suggestions:

• Is it possible that the ifup timeouts after loosing connection are related to a powersave setting of the wlan mod? I found several links dealing with this topic and addressing the problem of correct starting the wlan interface while powersave is activated. What is our status of the powersave?
• It could be worthwhile to start ifup with the -f argument.

[jonashoechst]

I've added verbosity to ifup / ifdown, and now do persist all logs from sensor proxy, as well as all its subprocesses.

Starting from now, we should be able to at lease see where problems from ifup / ifdown / wpa_supplicant come from. The concrete behavior described above should thus be explainable, when the matching logs are available.

The issue itself seems closed, but can be reopened, when arbitrary behavior with the current version occurs.