Has anybody succeeded with starting mjpg_streamer from within the sketch? I tried everything, but somehow I can't start the app, not even from calling shell script.
Has anybody succeeded with starting mjpg_streamer from within the sketch? I tried everything, but somehow I can't start the app, not even from calling shell script.
The mjpg_streamer is usually setup as daemon.
A daemon is a background, non-interactive program. It is detached from the keyboard and display of any interactive user. It could be setup as auto start when machine boot.
sonnyyu:
The mjpg_streamer is usually setup as daemon.
A daemon is a background, non-interactive program. It is detached from the keyboard and display of any interactive user. It could be setup as auto start when machine boot.
Nothing to do with sketch.
Hmm, let's say I understand that. But, what I don't understand is that I can disable the daemon from starting at boot and start it as a classic process as interactive user. I can also start and stop the daemon by invoking the script in /etc/init.d/ folder. I can also write a shell script doing the same thing, and invoke the script with exactly the same results.
But if I try ANY of that via Bridge and Process libraries, nothing works. And when in doubt, I alway start the example "WiFistatus" sketch which invokes some .lua script, and it's succesfull.
Just can't wrap my head around it. I'm failing big time somewhere, just can't see where.
m4dm4n:
Just can't wrap my head around it. I'm failing big time somewhere, just can't see where.
May not be the issue, but one thought is the current directory. When you are running any of those commands or shell scripts, are they making an assumption about the current directory? The current directory when you run the script from the Process object is not going to be the same one when you are running it from a command line.
When coding the command in the Process object call, it's best to always use an explicit full path name, don't make assumptions about the current directory. Same thing in any script files you write and then call with a Process object: either use full path names for every file or command access in the script, or start the script by changing to a known current directory.
This is issue is often the situation when a command works from the command line, but not a Process object call.
ShapeShifter:
May not be the issue, but one thought is the current directory. When you are running any of those commands or shell scripts, are they making an assumption about the current directory? The current directory when you run the script from the Process object is not going to be the same one when you are running it from a command line.
When coding the command in the Process object call, it's best to always use an explicit full path name, don't make assumptions about the current directory. Same thing in any script files you write and then call with a Process object: either use full path names for every file or command access in the script, or start the script by changing to a known current directory.
This is issue is often the situation when a command works from the command line, but not a Process object call.
#include <Bridge.h>
#include <Console.h>
#include <Process.h>
Process stream;
void setup() {
// put your setup code here, to run once:
delay(60000);
Bridge.begin();
Console.begin();
while(!Console);
Console.println("Bridge works, Console works!");
stream.runShellCommand("/usr/bin/mjpgstart.sh");
/*
stream.runShellCommand("/etc/init.d/mjpg-streamer start");
*/
/*
stream.begin("ash");
stream.addParameter("/usr/bin/mjpgstart.sh");
stream.run();
*/
}
void loop() {
// put your main code here, to run repeatedly:
}
This is my code, those things in comment don't work either.
You have several things. But I'll try to address both.
On the linux side, it is often the case you want to run a process from a script. You can use ash, the predecessor of bash.
The reason you want to use a shell script, is because it can setup your run environment. Many times the executioner (such as, Process) uses an execution library call that limits the run environment. This may be done as a security concern, or in the case of Yun a memory constraint issue. That is, the memory on the Atmel is limited, so only use the mostly like Process execution. Don't make allowances for every execution case.
In Linux, there are 6 distinct library calls that can execute a program. Google: linux exec library
This reference page will outline the technical methods: