I want to do the following -
#starting code
sleep(1000);
#remaining code
The starting code would run and get stuck at 'sleep'. After some time (<<1000), some other process would wake up this process by breaking this sleep(probably by sending a signal) and the rest of the program would run.
I have to use perl 5.6.1 on Windows, and it doesn't support alarm. I tried some signals like SIGINT, SIGFPE etc. but failed. Please suggest some alternative.
Are you using a signal handler? If not, SIGINT and its ilk will terminate your program.
my $parent_pid = $$;
# schedule interruption
if (fork() == 0) {
sleep 5;
kill 'INT', $parent_pid;
exit;
}
# trivial signal handler so SIGINT doesn't terminate the program
$SIG{INT} = sub { };
my $n = sleep 1_000_000;
print "Slept for $n seconds.\n";
On Linux, perl 5.6.2, this gives the output:
Slept for 5 seconds
For that matter, I don't know why you say alarm isn't supported on Perl 5.6 (unless you're on Windows maybe?) Again, set a signal handler or your program will terminate.
$SIG{ALRM} = sub {};
alarm 5;
$n = sleep 1_000_000;
print "slept for $n seconds\n";
works fine on my Perl 5.6.2.
Well, if I wanted to emulate
$SIG{ALRM} = \&handle_alarm;
alarm(5);
...
sleep(10);
I'd start with
use Time::HiRes qw( time sleep ); # Optional
my $alarm = time + 5;
...
my $timeout = $alarm - time;
if ($timeout <= 0) {
handle_alarm();
} else {
my $to_sleep = 10;
$to_sleep = $timeout if $timeout < $to_sleep;
sleep($to_sleep);
}
Related
I would like to trace all function calls for a given library in a process, but the process is going to exit and re-open regularly, and I want to keep tracing.
I am doing this now:
oneshot$target:LIBRARY::entry
{
printf("%s\n", probefunc);
}
However, this only lets me provide one pid at a time. Can I keep this going?
I want something like:
*:LIBRARY::entry
/execname == "foo"/
but that * doesn't work there.
Thanks!
I don't think you can do this with just a single dtrace script. You'd need two (at least...). And you need to have the ability to run the destructive system() action, which most likely means root access.
Assume you want to run this script on any new ls process:
#!/usr/sbin/dtrace -s
pid$1:libc::entry
{
printf( "func: %s\n", probefunc );
}
Assuming the path to that script is /root/dtrace/tracelibc.d, the following script will start dtrace on any new ls process that gets started. Note that you need #pragma D option destructive to be able to start dtrace on the new process:
#!/usr/sbin/dtrace -s
#pragma D option destructive
#pragma D option quiet
proc:::exec-success
/ "ls" == basename( execname ) /
{
printf( "tracing process %d\n", pid );
system( "/root/dtrace/tracelibc.d %d", pid );
}
That should work, but in this case ls is such a short-lived process that something like this happens quite often:
dtrace: failed to compile script /root/dtrace/tracelibc.d: line 10:
failed to grab process 12289
The process is gone by the time dtrace gets going. If you're tracing long-lived processes and don't care that you might miss the first few probes because dtrace takes a while to attach, you're done.
But, if you want to trace short-lived processes, you need to stop the process right when it starts, then restart it after dtrace attaches:
#!/usr/sbin/dtrace -s
#pragma D option destructive
#pragma D option quiet
proc:::exec-success
/ "ls" == basename( execname ) /
{
printf( "stopping process %d\n", pid );
system( "/root/dtrace/tracelibc.d %d", pid );
stop();
}
and start it back up in tracelibc.d:
#!/usr/sbin/dtrace -s
#pragma D option destructive
BEGIN
{
system( "prun %d", $1 );
}
pid$1:libc::entry
{
printf( "func: %s\n", probefunc );
}
Note that I'm using Solaris prun to restart the stopped process. You'd have to look at the Mac dtrace documentation for the stop() call to get the Mac equivalent of Solaris prun.
But... ooops. The two scripts above combine to produce:
stopping process 12274
dtrace: failed to compile script /root/dtrace/tracelibc.d: line 10:
probe description pid12274:libc::entry does not match any probes
Why does this say pid12274:libc::entry doesn't match any probes? Oh, yeah - when exec returns, the libc.so shared object hasn't been loaded into memory yet. We need a probe that's guaranteed to exist in the target process, and that gets called after libc.so is loaded, but before any processing gets done. main should suffice. So the main script to start it all becomes:
#!/usr/sbin/dtrace -s
#pragma D option destructive
#pragma D option quiet
proc:::exec-success
/ "ls" == basename( execname ) /
{
printf( "stopping process %d\n", pid );
system( "/root/dtrace/tracemain.d %d", pid );
stop();
}
That starts the tracemain.d script, that restarts the process, loads the tracelibc.d script, and stops the process again:
#!/usr/sbin/dtrace -s
#pragma D option destructive
#pragma D option quiet
BEGIN
{
system( "prun %d", $1 );
}
pid$1::main:entry
{
system( "/root/dtrace/tracelibc.d %d", $1 );
stop();
/* this instance of dtrace is now done */
exit( 0 );
}
And tracelibc.d adds its own system( "prun %d", $1 ); in the BEGIN probe, and it looks like:
#!/usr/sbin/dtrace -s
#pragma D option destructive
BEGIN
{
system( "prun %d", $1 );
}
pid$1:libc::entry
{
printf( "func: %s\n", probefunc );
}
Those three really slow up the ls process, but they do produce the expected output - and there's a lot of it, as expected.
I'm using the following perl code on windows environment:
use Time::HiRes qw(usleep);
#(some code here)
$self->{GLOBAL_OBJ}->xsleep($delay) if($delay);
sub xsleep {
my $seconds = shift;
#print "will sleep:$seconds seconds\n";
$seconds = $seconds * 1000000;
usleep($seconds);
#print "slept:$seconds micro seconds\n";
return 0;
}
When I call xsleep like that (from another module) the system is stuck and I can only stop it by ctrl+c, however when I call it from the current module it works fine.
Can anyone tell me why this is and how can I fix it?
Thanks
xsleep is being called as a method, which means the invocant (the result of the left side of ->) is passed as the first argument. This is currently ending up in $seconds. References numify to their address, so you get an extremely large numbers in $seconds. For example,
$ perl -e'CORE::say(0+{})'
9304720
Either adjust xsleep so it can be called as a method,
$self->{GLOBAL_OBJ}->xsleep($delay) if $delay;
sub xsleep {
my $self = shift;
my $seconds = shift;
...
}
or call xsleep as a sub
The::Package::xsleep($delay) if $delay;
sub xsleep {
my $seconds = shift;
...
}
I'd like to attach gdb to a process where I can't easily control the startup of the process because it is run from inetd and where the process completes too fast to be able to attach to it once it starts.
What I'd like to do is insert a bit of code at the particular point that I want to start debugging. That code would ideally wait for the debugger to attach and then continue. I've tried with a sleep but it is then tricky to choose a delay long enough that I have time to catch it but short enough not to be a nuisance waiting for it to elapse after gdb is attached.
Is there any better choices of code to insert or to call for this purpose?
What I'd like to do is insert a bit of code at the particular point that I want to start debugging.
I usually do it like this:
volatile int done = 0;
while (!done) sleep(1);
Attach GDB (you'll be inside sleep). Do finish, then set var done = 1, and enjoy the rest of your debugging session ;-)
using namespace std;
using namespace std::this_thread;
using namespace chrono;
void waitForDebugger()
{
steady_clock::time_point tp1, tp2, tp3;
microseconds d1 = microseconds(10000);
microseconds d2 = microseconds(20000);
bool looped = false;
while (true)
{
sleep_for(d1);
tp1 = steady_clock::now();
if (looped && duration_cast<microseconds>(tp1 - tp3) > d2)
{
break;
}
sleep_for(d1);
tp2 = steady_clock::now();
if (looped && duration_cast<microseconds>(tp2 - tp1) > d2)
{
break;
}
sleep_for(d1);
tp3 = steady_clock::now();
if (looped && duration_cast<microseconds>(tp3 - tp2) > d2)
{
break;
}
looped = true;
}
}
function spawn($exec, $args = array()) {
$pid = pcntl_fork();
if ($pid < 0)
return false;
else if ($pid == 0) {
$ppid = getmypid();
$pid = pcntl_fork();
if ($pid < 0)
file_put_contents('/tmp/error.log', "fork failed: ${cmd} ". implode(' ', $args). "\n");
else if ($pid == 0) {
pcntl_waitpid($ppid, $status);
pcntl_exec($exec, $args);
}
else
exit(0);
}
}
This works well in CLI mode.
But for php-fpm it causes the caller dead loop and then a timeout.
Why this happens?
It doesn't work because calling exit() under FPM doesn't cause the parent process to exit -- it just makes it clean up the request, then return to the pool of available worker processes. Since it never actually exits, the pcntl_waitpid ends up waiting forever.
As Roman Newaza notes, you should really avoid the pcntl functions under FPM (and, in general, outside CLI).
Process Control should not be enabled within a web server environment and unexpected results may happen if any Process Control functions are used within a web server environment: PCNTL/Introduction
I'm writing a tool that calls through to DTrace to trace the program that the user specifies.
If my tool uses dtrace -c to run the program as a subprocess of DTrace, not only can I not pass any arguments to the program, but the program runs with all the privileges of DTrace—that is, as root (I'm on Mac OS X). This makes certain things that should work break, and obviously makes a great many things that shouldn't work possible.
The other solution I know of is to start the program myself, pause it by sending it SIGSTOP, pass its PID to dtrace -p, then continue it by sending it SIGCONT. The problem is that either the program runs for a few seconds without being traced while DTrace gathers the symbol information or, if I sleep for a few seconds before continuing the process, DTrace complains that objc<pid>:<class>:<method>:entry matches no probes.
Is there a way that I can run the program under the user's account, not as root, but still have DTrace able to trace it from the beginning?
Something like sudo dtruss -f sudo -u <original username> <command> has worked for me, but I felt bad about it afterwards.
I filed a Radar bug about it and had it closed as a duplicate of #5108629.
Well, this is a bit old, but why not :-)..
I don't think there is a way to do this simply from command line, but as suggested, a simple launcher application, such as the following, would do it. The manual attaching could of course also be replaced with a few calls to libdtrace.
int main(int argc, char *argv[]) {
pid_t pid = fork();
if(pid == 0) {
setuid(123);
seteuid(123);
ptrace(PT_TRACE_ME, 0, NULL, 0);
execl("/bin/ls", "/bin/ls", NULL);
} else if(pid > 0) {
int status;
wait(&status);
printf("Process %d started. Attach now, and click enter.\n", pid);
getchar();
ptrace(PT_CONTINUE, pid, (caddr_t) 1, 0);
}
return 0;
}
This script takes the name of the executable (for an app this is the info.plist's CFBundleExecutable) you want to monitor to DTrace as a parameter (you can then launch the target app after this script is running):
string gTarget; /* the name of the target executable */
dtrace:::BEGIN
{
gTarget = $$1; /* get the target execname from 1st DTrace parameter */
/*
* Note: DTrace's execname is limited to 15 characters so if $$1 has more
* than 15 characters the simple string comparison "($$1 == execname)"
* will fail. We work around this by copying the parameter passed in $$1
* to gTarget and truncating that to 15 characters.
*/
gTarget[15] = 0; /* truncate to 15 bytes */
gTargetPID = -1; /* invalidate target pid */
}
/*
* capture target launch (success)
*/
proc:::exec-success
/
gTarget == execname
/
{
gTargetPID = pid;
}
/*
* detect when our target exits
*/
syscall::*exit:entry
/
pid == gTargetPID
/
{
gTargetPID = -1; /* invalidate target pid */
}
/*
* capture open arguments
*/
syscall::open*:entry
/
((pid == gTargetPID) || progenyof(gTargetPID))
/
{
self->arg0 = arg0;
self->arg1 = arg1;
}
/*
* track opens
*/
syscall::open*:return
/
((pid == gTargetPID) || progenyof(gTargetPID))
/
{
this->op_kind = ((self->arg1 & O_ACCMODE) == O_RDONLY) ? "READ" : "WRITE";
this->path0 = self->arg0 ? copyinstr(self->arg0) : "<nil>";
printf("open for %s: <%s> #%d",
this->op_kind,
this->path0,
arg0);
}
If the other answer doesn't work for you, can you run the program in gdb, break in main (or even earlier), get the pid, and start the script? I've tried that in the past and it seemed to work.
Create a launcher program that will wait for a signal of some sort (not necessarily a literal signal, just an indication that it's ready), then exec() your target. Now dtrace -p the launcher program, and once dtrace is up, let the launcher go.
dtruss has the -n option where you can specify name of process you want to trace, without starting it (Credit to latter part of #kenorb's answer at https://stackoverflow.com/a/11706251/970301). So something like the following should do it:
sudo dtruss -n "$program"
$program
There exists a tool darwin-debug that ships in Apple's CLT LLDB.framework which will spawn your program and pause it before it does anything. You then read the pid out of the unix socket you pass as an argument, and after attaching the debugger/dtrace you continue the process.
darwin-debug will exec itself into a child process <PROGRAM> that is
halted for debugging. It does this by using posix_spawn() along with
darwin specific posix_spawn flags that allows exec only (no fork), and
stop at the program entry point. Any program arguments <PROGRAM-ARG> are
passed on to the exec as the arguments for the new process. The current
environment will be passed to the new process unless the "--no-env"
option is used. A unix socket must be supplied using the
--unix-socket=<SOCKET> option so the calling program can handshake with
this process and get its process id.
See my answer on related question "How can get dtrace to run the traced command with non-root priviledges?" [sic].
Essentially, you can start a (non-root) background process which waits 1sec for DTrace to start up (sorry for race condition), and snoops the PID of that process.
sudo true && \
(sleep 1; cat /etc/hosts) &; \
sudo dtrace -n 'syscall:::entry /pid == $1/ {#[probefunc] = count();}' $! \
&& kill $!
Full explanation in linked answer.