-
Notifications
You must be signed in to change notification settings - Fork 18.7k
Open
Labels
FeatureRequestIssues asking for a new feature that does not need a proposal.Issues asking for a new feature that does not need a proposal.Proposal
Milestone
Description
Proposal Details
Proposal Details
'stress' is a useful tool to reproduce an error. But I found it a little inconvenient without the feature aforementioned. As I often got disrupted by other works or things and forgot that I was running a 'stress'. When I remembered to check the running, there were tons of error outputs (mostly caused by a bad command or networking issue) that were eating up my /tmp folder .
I think a simple option like '-e' (error limit) will work. The default behavior will be the same without this option: no limit will be set. If one specify how many errors to catch, 'stress' will stop at once when it hits the limit.
FYI, here is a latest v0.40.0 stress -h output:
$ stress -h
The stress utility is intended for catching sporadic failures.
It runs a given process in parallel in a loop and collects any failures.
Usage:
$ stress ./fmt.test -test.run=TestSometing -test.cpu=10
-count N
stop after N runs (default never stop)
-failure regexp
fail only if output matches regexp
-ignore regexp
ignore failure if output matches regexp
-kill
kill timed out processes if true, otherwise just print pid (to attach with gdb) (default true)
-o path
output failure logs to path plus a unique suffix (default "/tmp/go-stress-20251220T171803-")
-p N
run N processes in parallel (default 6)
-timeout duration
timeout each process after duration (default 10m0s)
Metadata
Metadata
Assignees
Labels
FeatureRequestIssues asking for a new feature that does not need a proposal.Issues asking for a new feature that does not need a proposal.Proposal