[PATCH v5 1/3] Introduce -l/--syscall-limit option

[Dmitry V. Levin]

On Sat, Apr 01, 2023 at 02:59:03AM +0530, Sahil Siddiq wrote:
> On Friday, 31 March 2023 17:03:20 IST Dmitry V. Levin wrote:
> > On Fri, Mar 31, 2023 at 12:14:13PM +0530, Sahil Siddiq wrote:
> > > On Friday, 31 March 2023 03:17:40 IST Kossi GLOKPOR wrote:
> > > > Hi,
> > > > What do you think about using the --daemonize options ? For example
> > > > with --daemonize=grandchild, the shell will be the parent of the
> > > > tracee, and detaching & stopping strace will have no incidence on it.
> > > > When we set an auto stop condition, we assume that strace can have to
> > > > stop while the tracee is still running, and enabling tracer
> > > > daemonization seems like a good way to prevent any issues with the
> > > > tracee when strace stops.
> > > > 
> > > > Regards,
> > > > Kossi
> > > 
> > > Thank you for the suggestion. I have tested this out and it gives the
> > > results that I was looking for. We could let "--syscall-limit" be enabled
> > > only when using it with the -D or -p options and disable it otherwise.
> > 
> > To be honest, although using --syscall-limit along with --daemonize makes
> > perfect sense, I'm not sure it is necessary to make this combination, or
> > combination of --syscall-limit with -p, mandatory.
> 
> Right, logically --syscall-limit should not be tied to the -D or -p options. But I
> was thinking of using it as a hack to work around the problem that arises after
> the tracees are detached. The detached tracee interferes with the foreground
> process in the terminal session which was initially used to run strace.

strace --daemonize has its own side effects.  For example, compared to a
regular strace invocation, it's harder to find out whether strace --daemonize
has finished writing its output.  That's why I'm reluctant to force
--daemonize option without giving user an option to turn it off.


-- 
ldv