FR: Allow shell commands to be tacked to the end of a sysdig call

[kristopolous]

The idea here is to make sysdig similar to strace.

With strace I can do something like

$ strace -e open firefox&

I'd like to be able to do something like that with sysdig

$ sysdig (options) firefox&

I talked with Loris on skype about this and said I'd be filing a ticket. Here it is officially

[kristopolous]

Please feel free to leave feedback in how you, the reader, would like to see this, or not see this. I'm intentionally sitting on my hands a few days to see what people will be saying about it

[luca3m]

I prefer the actual workflow rather than adding this behaviour

[kristopolous]

@luca3m I'm sorry, what do you mean by that?

[luca3m]

I mean that the actual workflow is good enough and I would prefer to avoid adding complexity for this feature.

[kristopolous]

Alright we have a clash here (I still care about you, don't worry!) How about an optional wrapper script that achieves this?

[ldegio]

my 2 cents: I do think that this feature could be useful in some cases, for example when you want to capture a new process in the same shell or in a noisy environment.

On the other hand, I definitely share Luca's concern about complexity. Sysdig is already very rich in features, and a new workflow like this one might make it more confusing to novice users.

@kristopolous, how do you suggest to address this with a script?

[kristopolous]

let's invent a syntax first. Mine will be that a fully-qualified path to an executable file is considered something to run. So for instance,

sysdigon -w dumpfile.scap /usr/bin/google-chrome

The wrapper looks for paths, in this case, it finds /usr/bin/google-chrome and starts it up, grabs the pid, appends it as a filter.

Will this always work? no. Will this work enough to be useful? sure. This is easy enough, I can write it in a separate repo and you can do whatever you want with it.

[dkogan]

Hi. I'd like to chime in also. I use sysdig a LOT, primarily for debugging. For my uses, I frequently want answers to questions like "where is this application looking for a file named 'xxxx'?" or "I see this application is getting a string 'yyyy' from somewhere; where does it come from?"

Here, the workflow with strace would be.

1. run './application', observe problem
2. run 'strace ./application' to debug

I want to use sysdig instead, because it's better a multitude of ways, and a new syntax like this would make it much nicer from my perspective. In addition, the other introspection tools (perf, strace, ltrace, etc) can all work like this, so this isn't a crazy thing to want.

From a practical perspective, currently the commandline option parsing is

sysdig [options or filters]

I propose extending it to

sysdig [options or filters] [-- command arg1 arg2 ...]

And in the latter case, only descendants of that command should be traced.

I don't have time to give yall a patch right now, but I'd like us at least to agree that something like this would be useful to have.

[ldegio]

OK, looks like we have two people with the requirement.

I would be willing to take the patch.

[kristopolous]

alright great ... we've already started.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.