dtrace discuss - Feb 2010 - dtrace -o and process substitution == illegal seek?

Hi all,

I''m working on a script where dtrace attaches to (or spawns) a process 
and the resulting dtrace output gets piped through a bunch of 
post-processing when the user hits ^C. So far this is what I have (in bash)

exec 3> >(<insert-pipeline-here>)
dtrace [args] >&3

The exec+process substitution makes it so only dtrace notices the ^C 
(otherwise post-processing gets killed along with the script).

Everything works beautifully when attaching to an existing process. 
Unfortunately, when dtrace spawns the process to be traced the above 
setup sends the process'' output through the post-processing instead of 
to stdout. The -o option for dtrace seemed ideal...

exec 3> >(<insert-pipeline-here>)
dtrace [args] -o >(cat >&3)

... but fails with

dtrace: failed to open output file ''/dev/fd/63'': Illegal seek

I imagine dtrace tried to truncate the output file... wouldn''t it be 
better to skip truncation for non-seekable files?

Meanwhile, is there a workaround? I need the program''s output to go to 
one stream and dtrace''s to another because the script is called by
other
scripts and there''s lots of redirection and pipelining going on.
Even without the externally imposed pain, managing and cleaning up tmp 
files is a pain because ^C makes the script exit in addition to dtrace 
(so no cleanup commands would be executed, and post-processing would 
have to be manually triggered after the fact).

Thanks,
Ryan

Well, it''s not a pretty workaround, but it works... Setting 
LD_PRELOAD_64 to the following shim library for dtrace avoids the bad 
call (apparently the open in append-mode is the culprit, causing a 
SEEK_END inside fopen)

===== fopen-noappend.c =====// gcc -g -m64 -c -fPIC -std=c99 fopen-noappend.c
// gcc -g -m64 -fPIC -std=c99 -shared -olibfopen-noappend64.so 
fopen-noappend.o -ldl
#include <stdio.h>
#include <dlfcn.h>
#include <string.h>

FILE* (*old_fopen)(const char *filename, const char *mode);

void __attribute__((constructor)) init_me() {
 old_fopen = dlsym(RTLD_NEXT, "fopen");
}

FILE* fopen(const char *filename, const char *mode) {
    char my_mode[100];
    if(strstr(filename, "/dev/fd/")) {
        strcpy(my_mode, mode);
        for(int i=0; my_mode[i]; i++) {
            if(my_mode[i] == ''a'')
                my_mode[i] = ''w'';
        }
        mode = my_mode;
    }
    return old_fopen(filename, mode);
}
===== fopen-noappend.c =====
Regards,
Ryan

Ryan Johnson wrote:
> Hi all,
>
> I''m working on a script where dtrace attaches to (or spawns) a
process
> and the resulting dtrace output gets piped through a bunch of 
> post-processing when the user hits ^C. So far this is what I have (in 
> bash)
>
> exec 3> >(<insert-pipeline-here>)
> dtrace [args] >&3
>
> The exec+process substitution makes it so only dtrace notices the ^C 
> (otherwise post-processing gets killed along with the script).
>
> Everything works beautifully when attaching to an existing process. 
> Unfortunately, when dtrace spawns the process to be traced the above 
> setup sends the process'' output through the post-processing
instead of
> to stdout. The -o option for dtrace seemed ideal...
>
> exec 3> >(<insert-pipeline-here>)
> dtrace [args] -o >(cat >&3)
>
> ... but fails with
>
> dtrace: failed to open output file ''/dev/fd/63'': Illegal
seek
>
> I imagine dtrace tried to truncate the output file... wouldn''t it
be
> better to skip truncation for non-seekable files?
>
> Meanwhile, is there a workaround? I need the program''s output to
go to
> one stream and dtrace''s to another because the script is called by
> other scripts and there''s lots of redirection and pipelining going
on.
> Even without the externally imposed pain, managing and cleaning up tmp 
> files is a pain because ^C makes the script exit in addition to dtrace 
> (so no cleanup commands would be executed, and post-processing would 
> have to be manually triggered after the fact).
>
> Thanks,
> Ryan
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org