This is a first post, so let me know if it needs to be done differently.
This is for a Yun with IDE 1.8.9.
What I have noticed is that the maximum accepted size of the parameters to the Process class seems to shrink over time.
To investigate this, I had a simple process call
echo 12345678
I found that echo 1234 would complete, but echo 123456 would fail and return nothing at all. After a complete reboot, reload, etc, things were back to normal.
Simply uploading a new sketch did not change things, so I was able to repeat the test and get consistent failures or passes based upon the length of the process parameter that was passed in. It makes no difference whether run or runShellCommand is used.
There are calls to Process made every few seconds. The program has been run continuously for several days. The program monitors the free-space and this remains constant. It takes about a day before the issue starts to show up. The rest of the program, including bridge operations, continues to run fine even after Process has developed this issue. There do not appear to be any obvious resource issues on the Linux side.
This was a tough problem to narrow down to this, so at least some of the grunt work is done.
But where do I go next? Presumably some resource that I am unaware of is having an issue. But what and where would that be? Where do we look and what do we monitor?
There was a post describing an issue with Process that mysteriously resolved itself. It seems that might be in a similar category, given what is required to duplicate the problem here.
Thanks for reading. Any pointers appreciated.
What's the type of arguments passed to echo? If it's a string, the digits may be interpreted as an address, with arbitrary result.
Can you post some code that shows this? If you can distill it down to the minimum amount of code that demonstrates the issue, that would be ideal. That way, others can try the code and see if the same thing happens.
Does the code reuse the same Process object over and over, or does it create/destroy the object each time?
Hi. Thanks for the replies there.
The original code would probably confuse more than help.
I think the gist of the echo command is the most appropriate bit. I may be able to write a simplified version to demonstrate that, but I don't have one handy at the moment.
I re-structured my program so that I had a listener on Linux and let it do the process handling.
This came up with another observation: Running lots of asynchronous requests to the bridge will eventually cause one of those requestors to lock up.
The solution to that problem appears to be to ensure that the requestors are separated in time by at least 200 milliseconds (100 wasn't enough). That seems to have added to the stability of the system overall. This is very much a rule-of-thumb thing, but maybe someone might find it useful. Can anyone corroborate that, perhaps?
Thanks again,
Richard
To answer one part of the question I missed in my reply: It uses the same Process object over and over.
I am working on a standalone test, but it may take while a while to produce results (a few days of run time, I think). And as usual in these cases, it might not cooperate.
Well, I tried to duplicate with a standalone program. That program has running two processes running every few seconds. It has run fine for the past 2 days.
In contrast, the original program I wrote had the Process keel over after a day, but continue to otherwise run fine until I upgraded it about a week later (I use 2 Yuns -- one for dev, other for deployment). This is rather perplexing, as one would assume a general memory or resource issue would have ultimately clobbered other things.
Sorry, I haven't come up with anything useful here. I wish I could have been more helpful. I will let it run some more, but I don't think it it will show the problem. I can try other things, if anyone has some ideas.
At the end of it, with my various program re-writes, everything is now seems very reliable. The deployment Yun is doing everything I asked of it. The WiFi, btw, is excellent; way better than I would have expected.
Richard.