Webiopi example app stops responding over night

774 views
Skip to first unread message

Mark Hibbins

unread,
Jan 15, 2013, 2:29:06 PM1/15/13
to web...@googlegroups.com
Hi,

I have been playing around with webiopi with an aim to building the features in to a remote control app which turns the heating on an off in my home office at the bottom of the garden. So far I've just been playing with the default app that's installed (this one) and it works really well and turns the relay I've built on and off perfectly from the browser on my phone.

The only thing that's stopping my going any further with it is that I've noticed that if I leave the pi running over night then by the next evening the webiopi web application no longer responds in a browser. The error I get in chrome is Error 7 (net::ERR_TIMED_OUT): The operation timed out. 

I know the pi is running as I can log in to it remotely via SSH and I can see that lighttpd is still responding on port 80 (webiopi is on 8000).

I can see that a webiopi is running...

root      1934     1  0 Jan14 ?        00:01:02 /usr/bin/python3 -m webiopi 8000

...but I can't see any log files.

Any ideas or is there any other information I can provide that would help?

Thanks,

Mark



trouch

unread,
Jan 15, 2013, 2:47:15 PM1/15/13
to web...@googlegroups.com
Hi Mark,
First, thanks for using this group !
I think I never got this issue, and I already ran webiopi for days.
I will take attention in next days.

There is currently no logging facility with the webiopi service
I have to add it but it's not planned yet.

You can try using screen :
$ screen
you will got a new virtual terminal with screen explanation, type enter.
you may have to install it (sudo aptitude install screen)
$ sudo python3 -m webiopi
it will run webiopi foreground with error output on the console
then type CTRL-A then D to detach from the screen and return to your previous terminal
your screen is still running, with webiopi inside, appart from your terminal/ssh
you can reattach the screen :
$ screen -x
then CTRL-A, then D to detach again...

when your webiopi crash, reattach the screen to see webiopi output.
if you don't find any screen, use the uptime command to see if your Pi didn't totally crash.

Eric/trouch

Mark Hibbins

unread,
Jan 15, 2013, 3:11:18 PM1/15/13
to web...@googlegroups.com
Hi Eric,

Thanks for answering so quickly. I've installed screen and started webiopi running as you suggest. I'll let you know the results.

Regards,

Mark
Message has been deleted
Message has been deleted

Mark Hibbins

unread,
Jan 17, 2013, 4:43:13 AM1/17/13
to web...@googlegroups.com
Eric, do you know why messages are being deleted from this group?

Mark

trouch

unread,
Jan 17, 2013, 4:58:34 AM1/17/13
to web...@googlegroups.com
Not at all, I supposed you deleted them :(

Mark Hibbins

unread,
Jan 17, 2013, 5:01:16 AM1/17/13
to web...@googlegroups.com
> Not at all, I supposed you deleted them :(

Hmm. Maybe it's because there's a link in it. This is a cut down version...

Hi Eric,

Bit of news but nothing helpful I suspect. Webiopi stopped responding again after roughly 24 hours. I reattached to the screen and there were no error messages I'm afraid.

The pi doesn't appear to be cpu bound or anything like that... it responds well and there's nothing hogging the cpu that I can see from 'ps -aux'.

One odd thing is that if I reattach to the screen and try and stop webiopi with ctrl-c it doesn't respond

I hope that helps but I suspect it doesn't. If there's any other information you need please let me know.

All the best,

Mark

trouch

unread,
Jan 17, 2013, 5:03:10 AM1/17/13
to web...@googlegroups.com
Did you tried a uptime command  after 24h ?
Did your Pi's IP change ?
Sorry, for convenience about posting problem, I'll check that.
Eric.

Mark Hibbins

unread,
Jan 17, 2013, 5:35:30 AM1/17/13
to trouch, web...@googlegroups.com
I didn't think about checking the uptime as I could still attach to the screen I started. I'll set it running again this evening and try it if it locks again.

The IP address didn't change. Although I'm running a DHCP server it's set to always give the same IP address to the pi.

Don't worry about the posts, there's probably some rule I broke with the content I posted. It contained the output from ps and other stuff and maybe that caused the message to be deleted.

I'm not very familiar with python (I'm a java developer) but I'm quite happy to get stuck in to code or install any debugging statements that would help. I think the idea and execution of what you've done is superb and fits my needs perfectly. I was going to start writing something from scratch so this saves me a lot of time so if there's anything I can do to help I'm more than willing to get my hands dirty if it helps.

All the best,

Mark

André Walenciak

unread,
Jan 17, 2013, 4:19:10 PM1/17/13
to web...@googlegroups.com
I had the same problem. The pi`s IP didn't change.

I fixed it with

crontab -e

and I added this line at the end of the file to restart the service every hour.

0 * * * * sudo /etc/init.d/webiopi restart

Andreas Riegg

unread,
Jan 30, 2013, 10:50:39 AM1/30/13
to web...@googlegroups.com
Hi Eric,
 
yesterday I encountered a similar problem when doing some kind of "brute-force" testing with my webiopi server (original 0.5.3 with 1 custom module).
 
During the last 2 weeks I had the Raspi with Webiopi server running 24/7 and did occationally Http/REST calls inside my LAN with my own Android native apps and all was fine. I was able to submit periodic calls with around 250 msec to a macro. Below this period, some communications errors happened, but this may also be due to delays and HTTP computing within Android so thats ok for me.
 
Then I tought I will do more. I established a certificate-based OpenVPN connection from my Phone via my home firewall and its OpenVPN connection server to see if I can communicate from outside with the Raspi. All was ok and working, only some delay in responsiveness could be remarked notably due to the overall less responsive UMTS connection. No surprise so far.
 
Then I thought I can do even more and established the same VPN when moving around with the Phone over a longer time and distance (e.g. walking around or in a moving car). It also worked but suddenly after a UMTS cell change or any other kind of lost connection I got no more response at all. Even frequent re-connecting the VPN did not help. The VPN however worked still fine as I have another server (not Raspi) in my LAN to which I can connect using a plain socket and this worked all the time. So the VPN was not the problem. But it came worse. After being home again I connected the Phone to the LAN and also got no response. Plus, I then used a PC browser to check and it also was not able to get a response from the webiopi http server. Surprisingly, when I did a network scan with Fing it still was able to find the Raspi and its open ports 22 for SSH and also 8000 for webiopi. I tried a SSH connection and it worked flawlesly, so I am sure that the raspi's linux sockets were still working fine. And I have a LED that is blinking driven by code in loop() within my custom module and it was still blinking so I am sure that the main thread of webiopi was still alive. I just solved the problem by restarting the custom module via SSH even without rebooting the Raspi, same idea as the poster above.
 
So I think the very unreliable UMTS connection when moving around (with presumably a lot of lost or damaged IP packages) somehow must have killed or blocked the HTTPServer thread in a way that the main Python application still runs but the HTTP server cannot respond any more even from the very clean LAN environment and/or other HTTP clients. However, this setup may be a real stress test and is far away from typical webiopi usage ...
 
As the whole webiopi server implementation is undergoing a major update right now that also adds much more logging possibilities, I will just wait until this release is out, try then to reproduce the problem and see which information I can get from the logs and maybe find out what kills or deadlocks the HTTPServer thread when having a very poor IP connection.
 
Regards Andreas

trouch

unread,
Jan 30, 2013, 11:04:21 AM1/30/13
to web...@googlegroups.com
As you mention, I hope logging facility of upcoming release will help solve this.
Deadlock is a good track as in can infer in no error output.
If so, the quicker fix is to add a cron task to restart webiopi sometime or use some watchdog to restart when it does not respond.
We'll see with the next release.

Eric.

Andreas Riegg

unread,
Jan 30, 2013, 4:24:47 PM1/30/13
to web...@googlegroups.com
Hi all,

Just a short update on the performance, I made some more testing and have to correct me. Within my LAN (Phone connected to my WLAN) I could get every 15ms a full JSON response (.../webiopi/*) from my rev1 Raspi running at 800 MHz (modest turbo without overvoltage). CPU for Python3 was about 40%. Could also get 10ms intervall at 45% CPU, but after 1 minute my Android app crashed (Galaxy S plus running 2.3.6). Seems with higher performant Phone I may be able to reach 5 ms which is quite impressive.

Andreas

trouch

unread,
Jan 30, 2013, 4:37:43 PM1/30/13
to web...@googlegroups.com
Thanks for this, I'm impressed by this results !
On my side, from my Macbook on WiFi, with a Pi REV1@700Mhz on Ethernet, I have :
25ms RTT on HTTP using Java Apache's http-client, which is near Chrome's results.
9ms RTT on CoAP using my Java CoAP client stack
Both with a POST request on /GPIO/x/value/

I plan to use json Python library instead of poor string concatenation.
I may ask for some other bench to see if there is a difference.

Eric.

Andreas

--
You received this message because you are subscribed to the Google Groups "WebIOPi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webiopi+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

trouch

unread,
Mar 16, 2013, 2:36:07 PM3/16/13
to web...@googlegroups.com
server hang up should be fixed with r1021. I added a 10s timeout on child socket.
The socket will be closed if no data received and the server will continue processing new requests.

trouch

unread,
Mar 16, 2013, 3:27:59 PM3/16/13
to web...@googlegroups.com
unfortunately, there is side effect to resolve...
Reply all
Reply to author
Forward
0 new messages