Regarding the --syscall-limit option

[Dmitry V. Levin]

On Sun, Apr 02, 2023 at 12:45:03AM +0530, Sahil Siddiq wrote:
> On Thursday, 30 March 2023 10:25:22 IST you wrote:
> > [...]
> > The options I have thought of are:
> > 
> > 1. to simply let "init" become the parent of the orphaned tracee after
> > strace terminates. But if the detached tracee is interactive, it may
> > interfere with current shell.
> > 
> > 2. to stop the tracee after strace terminates (which is probably not
> > desired).
> > 
> > 3. to let strace run and remain as the parent of the tracee without tracing
> > more syscalls. In this case, strace would have detached from the tracees
> > but it won't terminate. (I have understood that "-b execve" is per-tracee
> > and not global. However, I noticed that if every child/thread invokes
> > execve and "-b execve" detaches from all of those threads, strace still
> > remains the parent and does not terminate. In this case, strace would sleep
> > for a minute even after detaching from tracee in
> > "strace--syscall-limit.test"
> > 
> > Which approach would you suggest? Or is there another way that I could try
> > out?
> 
> Perf trace has an option called --max-events which is similar to --syscall-limit. I
> went throught perf's code in the linux git repository to see how it's been
> implemented there. In their implementation too, perf trace terminates after the
> specified number of syscalls while the tracee is reparented to init. I played around
> with this option and noticed that the tracee interferes with the controlling terminal
> when using this option in perf trace as well. Given this, would approach 1 be good
> enough?

Yes, I think so.


-- 
ldv