Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Sysdig capture running endless while using filters #1696

Open
Sarang-Sangram opened this issue Sep 30, 2020 · 3 comments
Open

Sysdig capture running endless while using filters #1696

Sarang-Sangram opened this issue Sep 30, 2020 · 3 comments
Labels
feature-request pinned

Comments

@Sarang-Sangram
Copy link

While running the sysdig capture without any filters the -M time value is picked up correctly and ends after the time specified time

[root@host2 bin]# sysdig -w my-sysdig.scap.gz -M 10 -z
[root@host2 bin]# ls
kubectl-capture  my-sysdig.scap.gz

But if I am using filters it just runs endless and require me to send the break single to end it

[root@host2 bin]# sysdig "container.name contains test-container" -w my-sysdig.scap.gz -M 10 -z
^C[root@host2 bin]#
@kristopolous
Copy link
Contributor

right the timing check happens after the filter so it'd run until the filter is matched. It could be moved up at a non-zero but ultimately meaningless cost. The real skill here would be to try to do it at almost no cost.

The other "bug" in the current implementation is the reference time stamp isn't set until the first matched packet. I call it a "bug" in quotes here because "capture for n seconds after the first match" is useful and it's what it currently does under these constraints.

So I guess the way to maintain this albeit undocumented backward compatibility would be to make the timer still start on first match and the capture stop after the time lapse.

I'll do a PR that does this "at cost" - at a likely unmeasurable overhead and hopefully we'll be good to go.

kristopolous added a commit to kristopolous/sysdig that referenced this issue Oct 17, 2020
@kristopolous
Fixes draios#1696 - Sysdig capture running endless while using filters
55437aa 
The timeout check was being after packets were filtered meaning
that a timeout could possibly never be observed.  This was changed
so the timeout check could be triggered by any event, not just ones
matching the filter.

Also, the start of the timer was being triggered by the first matched
event. This is a useful yet previously undocumented behavior so it
has been preserved and documented in the help text.
kristopolous added a commit to kristopolous/sysdig that referenced this issue Oct 18, 2020
@kristopolous
Fixes draios#1696 - Sysdig capture running endless while using filters
d94e605 
The timeout check was being after packets were filtered meaning
that a timeout could possibly never be observed.  This was changed
to introduce an optional system that allows people to specify whether
they want the clock to be triggered by any packet (a) or a filtered
match (f).  They can specify this optionally after the -M argument.

If a user uses a number with no argument, backwards compatibility is
maintained (which is 'ff'). Otherwise they can specify either 1 or
2 letters such as, for example "15aa" or "12af" or just "11a".

The help text has been modified to talk about these new options.
kristopolous added a commit to kristopolous/sysdig that referenced this issue Oct 18, 2020
@kristopolous
Fixes draios#1696 - Sysdig capture running endless while using filters
f0bc35f 
The timeout check was being after packets were filtered meaning
that a timeout could possibly never be observed.  This was changed
to introduce an optional system that allows people to specify whether
they want the clock to be triggered by any packet (a) or a filtered
match (f).  They can specify this optionally after the -M argument.

If a user uses a number with no argument, backwards compatibility is
maintained (which is 'ff'). Otherwise they can specify either 1 or
2 letters such as, for example "15aa" or "12af" or just "11a".

The help text has been modified to talk about these new options.
kristopolous added a commit to kristopolous/sysdig that referenced this issue Oct 18, 2020
@kristopolous
Fixes draios#1696 - Sysdig capture running endless while using filters
bc4dd30 
The timeout check was being after packets were filtered meaning
that a timeout could possibly never be observed.  This was changed
to introduce an optional system that allows people to specify whether
they want the clock to be triggered by any packet (a) or a filtered
match (f).  They can specify this optionally after the -M argument.

If a user uses a number with no argument, backwards compatibility is
maintained (which is 'ff'). Otherwise they can specify either 1 or
2 letters such as, for example "15aa" or "12af" or just "11a".

The help text has been modified to talk about these new options.
kristopolous added a commit to kristopolous/sysdig that referenced this issue Oct 18, 2020
@kristopolous
Fixes draios#1696 - Sysdig capture running endless while using filters
b266a99 
The timeout check was being after packets were filtered meaning
that a timeout could possibly never be observed.  This was changed
so the timeout check could be triggered by any event, not just ones
matching the filter.

Also, the start of the timer was being triggered by the first matched
event. This is a useful yet previously undocumented behavior so it
has been preserved and documented in the help text.
@kristopolous
Copy link
Contributor

so i've got two options for PRs to fix the issue. I like the second one myself - it's a stronger offering and maintains full backwards compatibility.

kristopolous added a commit to kristopolous/sysdig that referenced this issue Oct 18, 2020
@kristopolous
Fixes draios#1696 - Sysdig capture running endless while using filters
01f6edf 
The timeout check was being after packets were filtered meaning
that a timeout could possibly never be observed.  This was changed
to introduce an optional system that allows people to specify whether
they want the clock to be triggered by any packet (a) or a filtered
match (f).  They can specify this optionally after the -M argument.

If a user uses a number with no argument, backwards compatibility is
maintained (which is 'ff'). Otherwise they can specify either 1 or
2 letters such as, for example "15aa" or "12af" or just "11a".

The help text has been modified to talk about these new options.
kristopolous added a commit to kristopolous/sysdig that referenced this issue Oct 18, 2020
@kristopolous
Fixes draios#1696 - Sysdig capture running endless while using filters
176744a 
The timeout check was being after packets were filtered meaning
that a timeout could possibly never be observed.  This was changed
to introduce an optional system that allows people to specify whether
they want the clock to be triggered by any packet (a) or a filtered
match (f).  They can specify this optionally after the -M argument.

If a user uses a number with no argument, backwards compatibility is
maintained (which is 'ff'). Otherwise they can specify either 1 or
2 letters such as, for example "15aa" or "12af" or just "11a".

The help text has been modified to talk about these new options.
kristopolous added a commit to kristopolous/sysdig that referenced this issue Oct 18, 2020
@kristopolous
Fixes draios#1696 - Sysdig capture running endless while using filters
04ed52a 
The timeout check was being after packets were filtered meaning
that a timeout could possibly never be observed.  This was changed
to introduce an optional system that allows people to specify whether
they want the clock to be triggered by any packet (a) or a filtered
match (f).  They can specify this optionally after the -M argument.

If a user uses a number with no argument, backwards compatibility is
maintained (which is 'ff'). Otherwise they can specify either 1 or
2 letters such as, for example "15aa" or "12af" or just "11a".

The help text has been modified to talk about these new options.

sysdig-CLA-1.0-signed-off-by: Christopher McKenzie
<[email protected]>
kristopolous added a commit to kristopolous/sysdig that referenced this issue Oct 18, 2020
@kristopolous
Fixes draios#1696 - Sysdig capture running endless while using filters
4a98b77 
The timeout check was being after packets were filtered meaning
that a timeout could possibly never be observed.  This was changed
so the timeout check could be triggered by any event, not just ones
matching the filter.

Also, the start of the timer was being triggered by the first matched
event. This is a useful yet previously undocumented behavior so it
has been preserved and documented in the help text.

sysdig-CLA-1.0-signed-off-by: Christopher McKenzie
<[email protected]>
kristopolous added a commit to kristopolous/sysdig that referenced this issue Oct 18, 2020
@kristopolous
Fixes draios#1696 - Sysdig capture running endless while using filters
0123bb8 
The timeout check was being triggered only after filtered events
thus a timeout could possibly never be observed.  This was changed
so the timeout check could be triggered by any event, not just ones
matching the filter.

Also, the start of the timer was being triggered by the first matched
event. This is a useful yet previously undocumented behavior so it
has been preserved and documented in the help text.

sysdig-CLA-1.0-signed-off-by: Christopher McKenzie
<[email protected]>
kristopolous added a commit to kristopolous/sysdig that referenced this issue Oct 18, 2020
@kristopolous
Fixes draios#1696 - Sysdig capture running endless while using filters
4c5149b 
The timeout check was being triggered only by filter-matched events
which meant a timeout could possibly never be observed. This was changed
to introduce an optional system that allows people to specify whether
they want the clock to be triggered by any packet (a) or a filtered
match (f). They can specify this optionally after the -M argument.

If a user uses a number with no argument, backwards compatibility is
maintained (which is 'ff'). Otherwise they can specify either 1 or
2 letters such as, for example "15aa" or "12af" or just "11a".

The help text has been modified to talk about these new options.

sysdig-CLA-1.0-signed-off-by: Christopher McKenzie
<[email protected]>
@github-actions
Copy link

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.

@github-actions github-actions bot added the stale label Feb 22, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 2, 2023
@therealbobo therealbobo reopened this Mar 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature-request pinned
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@kristopolous @therealbobo @Sarang-Sangram