Hi, I''m trying to trace the io of a given file, but I have a feeling that it''s been done via a script, as such I''d like to be able to tell the names of the calling processe tree, similar to what ptree produces. Is there any way to get this information without running ptree using system()? Thanks, Darren.
Richard L. Hamilton
2007-May-31 07:41 UTC
[dtrace-discuss] Re: Determining Parent''s execname
Well, you could look at the source for ptree; after all, it probably just digs through /proc for this stuff. Although when I just did a truss of ptree, it seemed to be just looking at every entry in /proc and the corresponding /proc/N/psinfo file, rather than looking at the specified PID and following the pr_ppid entries back until it hits one with a pr_ppid of 1 (or of whatever the zone init process is, I suppose - not sure how that works without looking at the code myself...). I guess that makes sense when ptree is given multiple args (consolidating the output so it only shows common ancestors once), but it seems a bit inefficient to me for the case of a single argument. Anyway, a further complication is that ptree is run via isaexec, so as to be a 64-bit process (fully capable of examining other 64-bit processes as well as 32-bit processes) if run on a 64-bit kernel; that particular bit of behavior can''t be done without an exec, since any single executable can only be 32-bit or 64-bit, but not both at once. So if you wanted your program to be able to do that once it was running, you''d have to do the same thing, namely compile your program twice, once as 32-bit and once as 64-bit, put them in a directory structure that isaexec understood, and call it via a link to isaexec. IMO, not worth the bother. If it''s just system() that you don''t like, posix_spawn() should do the fork() and execve() without going through the shell as an intermediary, which would be faster and often safer. And posix_spawn() is both thread-safe and flexible (almost too many darn options, if anything). With a little work, you could duplicate what isaexec does and execute the /usr/bin/%s/ptree binary directly, where %s is the first value in the set by the SI_ISALIST option of sysinfo(2) for which that binary can be found; that would save the trip through the separate isaexec executable. Since posix_spawn() can apparently have implementation-specific additional attribute flags, I wonder if it might not be handy if one were added to cause it to use isaexec(3c) rather than execve(2). Anyone? Is that a warped idea, or a useful one? -- This message posted from opensolaris.org
Hi Richard,
Thanks for the response. The main reason that I wanted to do things without the
system call was that in the time it takes to do the system call, it is possible
for a process to have terminated - if for example it''s a simple CLI
command like
"rm").
The only way that I can seem to handle this is to call stop(), then run
system("ptree %d; prun %d", pid, pid).
Unfortunately this causes quite a slowdown in things - which I would have
preferred to avoid.
Thanks,
Darren.
Richard L. Hamilton wrote:> Well, you could look at the source for ptree; after all, it probably
> just digs through /proc for this stuff. Although when I just did a truss
> of ptree, it seemed to be just looking at every entry in /proc and the
> corresponding /proc/N/psinfo file, rather than looking at the specified
> PID and following the pr_ppid entries back until it hits one with a pr_ppid
of
> 1 (or of whatever the zone init process is, I suppose - not sure how that
> works without looking at the code myself...). I guess that makes sense
when
> ptree is given multiple args (consolidating the output so it only shows
> common ancestors once), but it seems a bit inefficient to me for the case
> of a single argument.
>
> Anyway, a further complication is that ptree is run via isaexec, so as to
be
> a 64-bit process (fully capable of examining other 64-bit processes as well
> as 32-bit processes) if run on a 64-bit kernel; that particular bit of
behavior
> can''t be done without an exec, since any single executable can
only be
> 32-bit or 64-bit, but not both at once. So if you wanted your program
> to be able to do that once it was running, you''d have to do the
same thing,
> namely compile your program twice, once as 32-bit and once as 64-bit,
> put them in a directory structure that isaexec understood, and call it via
> a link to isaexec.
>
> IMO, not worth the bother.
>
> If it''s just system() that you don''t like, posix_spawn()
should do the
> fork() and execve() without going through the shell as an intermediary,
> which would be faster and often safer. And posix_spawn() is both
> thread-safe and flexible (almost too many darn options, if anything).
> With a little work, you could duplicate what isaexec does and execute
> the /usr/bin/%s/ptree binary directly, where %s is the first value in
> the set by the SI_ISALIST option of sysinfo(2) for which that binary can
> be found; that would save the trip through the separate isaexec executable.
>
> Since posix_spawn() can apparently have implementation-specific additional
> attribute flags, I wonder if it might not be handy if one were added to
> cause it to use isaexec(3c) rather than execve(2). Anyone? Is that a
warped
> idea, or a useful one?
> --
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
You can get the parent details with something like: curthread->t_procp->p_parent->p_user.u_psargs and *its* parent with curthread->t_procp->p_parent->p_parent->p_user.u_psargs ... and so on. There will likely be some copy-and-paste involved in getting as much of the tree as you need. HTH Boyd On 31/05/2007, at 6:09 PM, Darren Kenny wrote:> Hi Richard, > > Thanks for the response. The main reason that I wanted to do things > without the > system call was that in the time it takes to do the system call, it > is possible > for a process to have terminated - if for example it''s a simple CLI > command like > "rm"). > > The only way that I can seem to handle this is to call stop(), then > run > system("ptree %d; prun %d", pid, pid). > > Unfortunately this causes quite a slowdown in things - which I > would have > preferred to avoid. > > Thanks, > > Darren. > > Richard L. Hamilton wrote: >> Well, you could look at the source for ptree; after all, it probably >> just digs through /proc for this stuff. Although when I just did >> a truss >> of ptree, it seemed to be just looking at every entry in /proc and >> the >> corresponding /proc/N/psinfo file, rather than looking at the >> specified >> PID and following the pr_ppid entries back until it hits one with >> a pr_ppid of >> 1 (or of whatever the zone init process is, I suppose - not sure >> how that >> works without looking at the code myself...). I guess that makes >> sense when >> ptree is given multiple args (consolidating the output so it only >> shows >> common ancestors once), but it seems a bit inefficient to me for >> the case >> of a single argument. >> >> Anyway, a further complication is that ptree is run via isaexec, >> so as to be >> a 64-bit process (fully capable of examining other 64-bit >> processes as well >> as 32-bit processes) if run on a 64-bit kernel; that particular >> bit of behavior >> can''t be done without an exec, since any single executable can >> only be >> 32-bit or 64-bit, but not both at once. So if you wanted your >> program >> to be able to do that once it was running, you''d have to do the >> same thing, >> namely compile your program twice, once as 32-bit and once as 64-bit, >> put them in a directory structure that isaexec understood, and >> call it via >> a link to isaexec. >> >> IMO, not worth the bother. >> >> If it''s just system() that you don''t like, posix_spawn() should do >> the >> fork() and execve() without going through the shell as an >> intermediary, >> which would be faster and often safer. And posix_spawn() is both >> thread-safe and flexible (almost too many darn options, if anything). >> With a little work, you could duplicate what isaexec does and execute >> the /usr/bin/%s/ptree binary directly, where %s is the first value in >> the set by the SI_ISALIST option of sysinfo(2) for which that >> binary can >> be found; that would save the trip through the separate isaexec >> executable. >> >> Since posix_spawn() can apparently have implementation-specific >> additional >> attribute flags, I wonder if it might not be handy if one were >> added to >> cause it to use isaexec(3c) rather than execve(2). Anyone? Is >> that a warped >> idea, or a useful one? >> -- >> This message posted from opensolaris.org >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
That works just lovely, knew there had to be some way to get these values, I''m just not familiar enough with the structures... Now there''s hardly any effect on the system and I can turn off the "-w" flag... Thanks, Darren. Boyd Adamson wrote:> You can get the parent details with something like: > > curthread->t_procp->p_parent->p_user.u_psargs > > and *its* parent with > > curthread->t_procp->p_parent->p_parent->p_user.u_psargs > > ... and so on. > > There will likely be some copy-and-paste involved in getting as much > of the tree as you need. > > HTH > > Boyd > > On 31/05/2007, at 6:09 PM, Darren Kenny wrote: > >> Hi Richard, >> >> Thanks for the response. The main reason that I wanted to do things >> without the >> system call was that in the time it takes to do the system call, it >> is possible >> for a process to have terminated - if for example it''s a simple CLI >> command like >> "rm"). >> >> The only way that I can seem to handle this is to call stop(), then >> run >> system("ptree %d; prun %d", pid, pid). >> >> Unfortunately this causes quite a slowdown in things - which I >> would have >> preferred to avoid. >> >> Thanks, >> >> Darren. >> >> Richard L. Hamilton wrote: >>> Well, you could look at the source for ptree; after all, it probably >>> just digs through /proc for this stuff. Although when I just did >>> a truss >>> of ptree, it seemed to be just looking at every entry in /proc and >>> the >>> corresponding /proc/N/psinfo file, rather than looking at the >>> specified >>> PID and following the pr_ppid entries back until it hits one with >>> a pr_ppid of >>> 1 (or of whatever the zone init process is, I suppose - not sure >>> how that >>> works without looking at the code myself...). I guess that makes >>> sense when >>> ptree is given multiple args (consolidating the output so it only >>> shows >>> common ancestors once), but it seems a bit inefficient to me for >>> the case >>> of a single argument. >>> >>> Anyway, a further complication is that ptree is run via isaexec, >>> so as to be >>> a 64-bit process (fully capable of examining other 64-bit >>> processes as well >>> as 32-bit processes) if run on a 64-bit kernel; that particular >>> bit of behavior >>> can''t be done without an exec, since any single executable can >>> only be >>> 32-bit or 64-bit, but not both at once. So if you wanted your >>> program >>> to be able to do that once it was running, you''d have to do the >>> same thing, >>> namely compile your program twice, once as 32-bit and once as 64-bit, >>> put them in a directory structure that isaexec understood, and >>> call it via >>> a link to isaexec. >>> >>> IMO, not worth the bother. >>> >>> If it''s just system() that you don''t like, posix_spawn() should do >>> the >>> fork() and execve() without going through the shell as an >>> intermediary, >>> which would be faster and often safer. And posix_spawn() is both >>> thread-safe and flexible (almost too many darn options, if anything). >>> With a little work, you could duplicate what isaexec does and execute >>> the /usr/bin/%s/ptree binary directly, where %s is the first value in >>> the set by the SI_ISALIST option of sysinfo(2) for which that >>> binary can >>> be found; that would save the trip through the separate isaexec >>> executable. >>> >>> Since posix_spawn() can apparently have implementation-specific >>> additional >>> attribute flags, I wonder if it might not be handy if one were >>> added to >>> cause it to use isaexec(3c) rather than execve(2). Anyone? Is >>> that a warped >>> idea, or a useful one? >>> -- >>> This message posted from opensolaris.org >>> _______________________________________________ >>> dtrace-discuss mailing list >>> dtrace-discuss at opensolaris.org >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
On Thu, May 31, 2007 at 12:41:33AM -0700, Richard L. Hamilton wrote:> If it''s just system() that you don''t like, posix_spawn() should do the > fork() and execve() without going through the shell as an intermediary, > which would be faster and often safer. And posix_spawn() is both > thread-safe and flexible (almost too many darn options, if anything).Just to clear up some confusion, the original question was referring to the system() action in DTrace not the system(3c) libc call. Also posix_spawn() -- while potentially more convenient -- is probably no faster than a fork and exec since it''s implemented in terms of them. Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl