Yun CURL command fails to work after a while

Hi all,

I’m encountering a strange issue whereby after a while (the last case was 2.5 days) the CURL command stops executing properly in my sketch.

My sketch executes a CURL command every few minutes and posts data to a page I created to receive and log the data into a DB table. For example below is a function which fires off a CURL post to my site:

void SendGarageRollerDoorStatus(String status)
{
  Process p;
  String cmd = "curl --data \"GarageRollerDoorStatus="+status;
  cmd = cmd + "\" http://mysite.com/arduino.php";
  p.runShellCommand(cmd);

  Console.println("START Ping----------");
  Console.println(cmd);
  p.close();
  Console.println("Sent Garage Roller Door Status = "+status);
  Console.println("END   Ping----------");
  Console.println("");
}

After a while the CURL is not being fired off. I can tell because nothing is showing up in my DB tables whereas prior to it stopping, it had been logging the CURL post data every few minutes. In the last case I’d received 1439 posts from the Arduino perfectly OK then it just stops.

When the issue occurs, the Arduino is up and running fine and has full network connectivity out to the internet and back. From my smart phone on mobile network I can send REST commands to it via a URL e.g.

http:///arduino/hello

and the Arduino Yun responds back. In my case “Arduino is here and ready”.

Also if I SSH into my Arduino Yun, from the CLI, I can fire off a CURL command exactly as in my sketch e.g:

curl --data "GarageRollerDoorStatus=closed" http://mysite.com/arduino.php

And it fires off all ok and is logged in my DB tables.

If I open the serial monitor, everything looks fine and the function is being executed as the Console.println texts are appearing as expected.

So my conclusions are:

-Network connectivity to and from the Arduino are not the issue.
-The linux side is not the issue as I can fire off the exact same command as the sketch should be executing without issue.

I am lost. Any ideas?

Rebooting fixes the issue straight away.

BTW I am running build version:

cat /etc/arduino/openwrt-yun-release
built=Fri Oct 10 02:41:25 CEST 2014

The change logs for the newer versions don’t seem to indicate anything that might fix this.

Many thanks in advance,
Adrian

Next time it happens, try resetting just the 32U4 processor (use the 32U4 RST button.) I wonder if it might be a memory leak in your sketch? (Failing over time is a classic symptom of memory issues.)

gabbatron:
When the issue occurs, the Arduino is up and running fine and has full network connectivity out to the internet and back. From my smart phone on mobile network I can send REST commands to it via a URL e.g.

http:///arduino/hello

and the Arduino Yun responds back. In my case “Arduino is here and ready”.

I agree with ShapeShifter, it may be a memory leak problem. But what you stated in the quoted message seems to prove that the 32u4 is working.

I’m confused :smiley:

Can you share more code?

Angelo9999:
But what you stated in the quoted message seems to prove that the 32u4 is working.

Yes, the sketch has clearly not completely crashed. Resetting the 32U4 is a shot in the dark, but worth it since it's such an easy test. If nothing else, it may help narrow down whether the problem is on the Linux or Sketch side.

@all,
Respectfully, I disagree. I suspect the Wifi is locking up the socket.

FWIW: I personally know the author of the socket driver. He was contracted for Atheros at the time and when we had a round table discussion at the BAFUG (Bay Area Freebsd User Group), I questioned some of his test procedures. His responses, in my opinion, were lacking. He has threatened to start a new OS group for FreeBSD that has the YUN as it's jumping off point.

In any case, my suspicion is that the current Atheros chipset is subject to intermittent failures - without a recovery available in software.

WHAT TO DO.
#1 I would follow the course already set out. REBOOT the 32U4.
#2 if #1 fails, toggle the wifi on and off for 10 seconds.
#3 if that fails, then we should get some memory reading from the Linux side, checking buffers and sockets.

After that we'd have to do invasive diagnostics, which I think the OP would not appreciate.
By invasive, I mean a hard reset of the radio - which I do NOT know how to do -- yet.

Jesse

Hi guys,

Thanks for the replies.

@jessemonroy650 - The wifi is not hooked up to my wifi network. It is running of an ethernet cable. It was on wifi but I thought I would move to ethernet to see if it would fix it. BTW I factory reset the YUN and ensured that I didn't specify any wifi credentials so it is 100% going through ethernet.

I'm going to clean up the code a bit to make it easier to read, so I can share it. I really just put it all together with the focus on getting it working and then a clean up later.

For debugging purposes I do a lot of "console.println" and "console.print" so I can see what is happening over the serial monitor. Should I be using "console.flush" at the end of my sketch? i.e. end of the main loop (void loop())

Is there anything in particular or generically about my skwtch code that I should look for that might cause a memory leak?

I will try the reset of the 32U4 processor to see if that resolves the issue when it occurs.

I'll also have a loop at the memory usage on the linux side via the TOP command. When I looked in there I only looked at CPU usage and the CPU has very low utilisation when I have checked it when the issue is occurring.

The easy route would be to plug the power supply for the Yun into a power timer so it cuts the power off and back on once per day. But that would be too easy and just a band aid solution.

Thanks everyone.

Why do you call close() method of the Process object?
The method is needed when you start a process by runAsynchronously() but the process is started by runShellCommand().

I don't know the method causes memory leak or not, it might be good to delete the dubious code.

tasasaki:
Why do you call close() method of the Process object?
The method is needed when you start a process by runAsynchronously() but the process is started by runShellCommand().

http://www.arduino.cc/en/Reference/YunProcessClose

I don't know the method causes memory leak or not, it might be good to delete the dubious code.

The close() method should be always called. It deletes the handle of an unused process.

If you look at the source code of the library the runShellCommand uses the runAsynchronously method inside it and then manages the waiting, so calling the close method is always a good practice.

@Angelo9999
Oh thanx, I didn't know it. I found runShellCommand() method in libraries/Bridge/src/Process.cpp.
The run() method also call runAsynchronously(), I was surprised a bit.

@tasasaki Thank you very much. This fixed it perfectly. All I did was comment out the lines that had:

p.close()

Sorry for not replying sooner.

Ever since making the change it went from needing a reboot every few days to going months and months without a reboot.

tasasaki:
Why do you call close() method of the Process object?
The method is needed when you start a process by runAsynchronously() but the process is started by runShellCommand().

http://www.arduino.cc/en/Reference/YunProcessClose

I don't know the method causes memory leak or not, it might be good to delete the dubious code.

Hi,
I am using the Yun and using the Curl command to log data. Yun performs well for the first 10 to 12 hours and it stops submitting. I can view the console and it checks all sensors calculates and outputs right value, just doesn't submit to the web. I have included p.close () and p.flush () to clear. it hasn't work, yun stopped submitting after 11 hours. I submit data every 10 s or so and logDataToCloud function is called everytime. I have no idea what is going on please help .

void logDataToCloud(String SensorName, String Data){

Process SendToAPI;

SendToAPI.begin("curl");
SendToAPI.addParameter("-X");
SendToAPI.addParameter("POST");
SendToAPI.addParameter("--data");
SendToAPI.addParameter("D="+MacAddress+";"+SensorName+";"+Data);
SendToAPI.addParameter("url goes here");
SendToAPI.run();
SendToAPI.close();
SendToAPI.flush();
}

lanternLadd:
I have included p.close () and p.flush () to clear. it hasn't work, yun stopped submitting after 11 hours. I submit data every 10 s or so and logDataToCloud function is called everytime.

You are calling Process.close(), but this thread seems to indicate that calling that function in the context of Process.run() causes it to stop responding after a while. The author of the post immediately above yours says he fixed his similar problem by removing the call to Process.close().

That seems to make some sense since your Process object is declared locally in the function. The object is created upon entry to the function, and its destructor will be automatically called when the function returns. The Process object's destructor calls close(), so in essence the end of your function is calling close(), then flush(), then close(). Wasteful and redundant at best, and two close() calls could be a problem that causes your issues.

You are also calling Process.flush() - I would normally think you would want to flush a stream before closing it. In my mind, there doesn't seem to be any benefit to flushing a closed stream. But in this case, it doesn't matter, as the source code for Process.flush() shows that it's an empty function that does nothing - there is no practical reason for that call to be there.

I would try removing the Process.close() and Process.flush() lines from your logDataToCloud() function and see how long it runs.