I have a code that use popen to execute a script ,It works fine but randomly it's blocking and getting CPU to 100% ,after a little investigation I discover that it hangs on popen calls. I have put a printf after the popen showing the descriptor asigned and in this case when it blocks this printf never shows.
What can cause popen to block?
Edit: Code
FILE* pipe = popen(cpCommand, "r");
printf(....
if (pipe)
{
while (!feof(pipe))
{
if (DataReady(fileno(pipe),2500)>0)
{
if (fgets(output,sizeof(output),pipe) != NULL)
{
DataReady is just a select..
I have done a strace after it blocks and it seems to not doing anything
Not an answer ;-)
Try use strace to what it's doing and which syscall hangs.
Tterminal output is line-buffered, so make sure to flush output by using fflush() or using a newline (fflush(stdout); or printf("Debug text\n");) to ensure it doesn't really call the printf().
Run the script manually and ensure the script doesn't hang intermittently before suspecting popen().
Check the script called by popen() why it doesn't end.
As long a s the script does not end, popen() blocks, will say: does not return, as observed.
I strongly doubt this is a C issue.
Related
I wrote a c++ program to check if a process is running or not . this process is independently launched at background . my program works fine when I run it on foreground but when I time schedule it, it do not work .
int PID= ReadCommanOutput("pidof /root/test/testProg1"); /// also tested with pidof -m
I made a script in /etc/cron.d/myscript to time schedule it as follows :-
45 15 * * * root /root/ProgramMonitor/./testBkg > /root/ProgramMonitor/OutPut.txt
what could be the reason for this ?
string ReadCommanOutput(string command)
{
string output="";
int its=system((command+" > /root/ProgramMonitor/macinfo.txt").c_str());
if(its==0)
{
ifstream reader1("/root/ProgramMonitor/macinfo.txt",fstream::in);
if(!reader1.fail())
{
while(!reader1.eof())
{
string line;
getline(reader1,line);
if(reader1.fail())// for last read
break;
if(!line.empty())
{
stringstream ss(line.c_str());
ss>>output;
cout<<command<<" output = ["<<output<<"]"<<endl;
break;
}
}
reader1.close();
remove("/root/ProgramMonitor/macinfo.txt");
}
else
cout<<"/root/ProgramMonitor/macinfo.txt not found !"<<endl;
}
else
cout<<"ERROR: code = "<<its<<endl;
return output;
}
its output coming as "ERROR: code = 256"
thanks in advacee .
If you really wanted to pipe(2), fork(2), execve(2) then read the output of a pidof command, you should at least use popen(3) since ReadCommandOutput is not in the Posix API; at the very least
pid_t thepid = 0;
FILE* fpidof = popen("pidof /root/test/testProg1");
if (fpidof) {
int p=0;
if (fscanf(fpidof, "%d", &p)>0 && p>0)
thepid = (pid_t)p;
pclose(fpidof);
}
BTW, you did not specify what should happen if several processes (or none) are running the testProg1....; you also need to check the result of pclose
But you don't need to; actually you'll want to build, perhaps using snprintf, the pidof command (and you should be scared of code injection into that command, so quote arguments appropriately). You could simply find your command by accessing the proc(5) file system: you would opendir(3) on "/proc/", then loop on readdir(3) and for every entry which has a numerical name like 1234 (starts with a digit) readlink(2) its exe entry like e.g. /proc/1234/exe ...). Don't forget the closedir and test every syscall.
Please read Advanced Linux Programming
Notice that libraries like Poco or toolkits like Qt (which has a layer QCore without any GUI, and providing QProcess ....) could be useful to you.
As to why your pidof is failing, we can't guess (perhaps a permission issue, or perhaps there is no more any process like you want). Try to run it as root in another terminal at least. Test its exit code, and display both its stdout & stderr at least for debugging purposes.
Also, a better way (assuming that testProg1 is some kind of a server application, to be run in at most one single process) might be to define different conventions. Your testProg1 might start by writing its own pid into /var/run/testProg1.pid and your current application might then read the pid from that file and check, with kill(2) and a 0 signal number, that the process is still existing.
BTW, you could also improve your crontab(5) entry. You could make it run some shell script which uses logger(1) and (for debugging) runs pidof with its output redirected elsewhere. You might also read the mail perhaps sent to root by cron.
Finally I solved this problem by using su command
I have used
ReadCommanOutput("su -c 'pidof /root/test/testProg1' - root");
insteadof
ReadCommanOutput("pidof /root/test/testProg1");
I start programs from a C++ program in linux as follows:
char* cmd = "/bin/snmpd &"; // command to execute
FILE* pipe = popen(cmd, "r"); // pipe to command line
if (!pipe) return -1; // check if pipe worked
pclose(pipe); // close pipe
return 1; // return
Now that starts snmpd, but, the problem is, when this C++ program closes, snmpd closes with it. How do you start a linux program from another C++ program without program being started being dependant on the program starting it?
The way you're starting the program, you're telling the system
that all output from the program to standarrd out should go into
a pipe to your program. A pipe which you then close. Writing
to a pipe which was closed causes a SIG_PIPE; unless the
program you start does something special with this signal, it
will be terminated.
If you're not interested in the output from the program, you
should use the standard function system to start it:
system( "/bin/snmpd &" );
should do the trick in your case. (system will start
a subshell, and wait for the subshell to finish, but the &
means that the subshell won't wait for snmpd to finish.)
Depending on what you are doing, you may want to "demonize" the
process you start, deconnecting it from your process group, so
that it won't be killed even if you log off. I'm less sure
about this (I've always done it at a lower level), but I think
just redirecting standard out and standard error (and maybe also
standard in) to use /dev/null should do the trick:
system( "/bin/snmpd < /dev/null > /dev/null 2>&1 &" );
If popen doesn't do exactly what you want, don't use it. Instead, use pipe, fork, exec, daemonize, setsid, and so on to implement exactly the behavior you want. Look at an example popen implementation for a starting point.
When writing my server code I have this line:
newsockfd = accept(sockfd, (struct sockaddr *)&cli_addr, &clilen);
When I run the program I get no errors, but the program just freezes, and I put a print statement at the first line of the main() (so it should run before anything runs)
but the print statement never gets executed.
This line of code is definitely the problem because once I comment it out, my print statements work.
What might create such bizarre behavior?
(I'm not allowed to post homework code, so unfortunately I can't post all of it)
Since this was apparently the answer, I'll write it here: If your printf format strings don't end with "\n", then they'll be buffered until either you do print a newline or your program exits. (I'm simplifying a bit.) Since your accept call stopped your program after that output was buffered, you couldn't see the output even though the printf calls were working fine.
The other option for you is to fflush() the stdout, which will force it to "print" anything buffered regardless of the '\n':
printf("print this now!");
fflush(stdout);
It's waiting for a connection. That's the purpose of the accept function.
I am having trouble using system() from libc on Linux. My code is this:
system( "tar zxvOf some.tar.gz fileToExtract | sed 's/some text to remove//' > output" );
std::string line;
int count = 0;
std::ifstream inputFile( "output" );
while( std::getline( input, line != NULL ) )
++count;
I run this snippet repeatedly and occasionally I find that count == 0 at the end of the run - no lines have been read from the file. I look at the file system and the file has the contents I would expect (greater than zero lines).
My question is should system() return when the entire command passed in has completed or does the presence of the pipe '|' mean system() can return before the part of the command after the pipe is completed?
I have explicitly not used a '&' to background any part of the command to system().
To further clarify I do in practice run the code snippet multiples times in parallel but the output file is a unique filename named after the thread ID and a static integer incremented per call to system(). I'm confident that the file being output to and read is unique for each call to system().
According to the documentation
The system() function shall not return until the child process has terminated.
Perhaps capture the output of "output" when it fails and see what it is? In addition, checking the return value of system would be a good idea. One scenario is that the shell command you are running is failing and you aren't checking the return value.
system(...) calls the standard shell to execute the command, and the shell itself should return only after the shell has regained control over the terminal. So if there's one of the programs backgrounded, system will return early.
Backgrounding happens through suffixing a command with & so check if the string you pass to system(...) contains any & and if so make sure they're properly quoted from shell processing.
System will only return after completion of its command and the file output should be readable in full after that. But ...
... multiple instances of your code snippet run in parallel would interfere because all use the same file output. If you just want to examine the contents of output and do not need the file itself, I would use popen instead of system. popen allows you to read the output of the pipe via a FILE*.
In case of a full file system, you could also see an empty output while the popen version would have no trouble with this condition.
To notice errors like a full file system, always check the return code of your calls (system, popen, ...). If there is an error the manpage will tell you to check errno. The number errno can be converted to a human readable text by strerror and output by perror.
I'm working on a init for an initramfs in C++ for Linux. This script is used to unlock the DM-Crypt w/ LUKS encrypted drive, and set the LVM drives to be available.
Since I don't want to have to reimplement the functionality of cryptsetup and gpg I am using system calls to call the executables. Using a system call to call gpg works fine if I have the system fully brought up already (I already have a bash script based initramfs that works fine in bringing it up, and I use grub to edit the command line to bring it up using the old initramfs). However, in the initramfs it never even acts like it gets called. Even commands like system("echo BLAH"); fail.
So, does anyone have any input?
Edit: So I figured out what was causing my errors. I have no clue as to why it would cause errors, but I found it.
In order to allow hotplugging, I needed to write /sbin/mdev to /proc/sys/kernel/hotplug...however I ended up switching around the parameters (on a function I wrote myself no less) so I was writing /proc/sys/kernel/hotplug to /sbin/mdev.
I have no clue as to why that would cause the problem, however it did.
Amardeep is right, system() on POSIX type systems runs the command through /bin/sh.
I doubt you actually have a legitimate need to invoke these programs you speak of through a Bourne shell. A good reason would be if you needed them to have the default set of environment variables, but since /etc/profile is probably also unavailable so early in the boot process, I don't see how that can be the case here.
Instead, use the standard fork()/exec() pattern:
int system_alternative(const char* pgm, char *const argv[])
{
pid_t pid = fork();
if (pid > 0) {
// We're the parent, so wait for child to finish
int status;
waitpid(pid, &status, 0);
return status;
}
else if (pid == 0) {
// We're the child, so run the specified program. Our exit status will
// be that of the child program unless the execv() syscall fails.
return execv(pgm, argv);
}
else {
// Something horrible happened, like system out of memory
return -1;
}
}
If you need to read stdout from the called process or send data to its stdin, you'll need to do some standard handle redirection via pipe() or dup2() in there.
You can learn all about this sort of thing in any good Unix programming book. I recommend Advanced Programming in the UNIX Environment by W. Richard Stevens. The second edition coauthored by Rago adds material to cover platforms that appeared since Stevens wrote the first edition, like Linux and OS X, but basics like this haven't changed since the original edition.
I believe the system() function executes your command in a shell. Is the shell executable mounted and available that early in your startup process? You might want to look into using fork() and execve().
EDIT: Be sure your cryptography tools are also on a mounted volume.
what do you have in initramfs ? You could do the following :
int main() {
return system("echo hello world");
}
And then strace it in an initscript like this :
strace -o myprog.log myprog
Look at the log once your system is booted