Hi,
after stages duration finished also one of my script continuously running with one vuser… i am using version 24 and here is the stages options i am using:
{"stages":[
{"duration":"60s","target":10},{"duration":"120s"},
{"duration":"60s","target":15},{"duration":"180s"},{"duration":"60s","target":0}]};
i am using function for statuscheck in my script … is that casuing single user running always after duration is finished?
function statusCheck() { resp = http.get(`${Url}/xxxxxxxx/xxxxx`,headers)
check(resp, {"check resp 200": res => res.status === 200}); if (resp.body !== "Complete")
{statusCheck();}}
statusCheck();
Hi @ravi_k6, I highly doubt that that is the problem ;).
Can you show us what is written between the k6 logo and the “progressbar”, like this part:
WARN[0000] There were problems with the specified script configuration:
- scheduler default has errors: stage 2 doesn't have a target, stage 4 doesn't have a target
execution: local
output: -
script: t.js
duration: -, iterations: -
vus: 1, max: 15
I am pretty sure it is this old issue but we will need to see the duration/iteration values
p.s. as you can see when you run your script with the stages you provided you get a warning that stages without targets are used. This will become an error in the next version so … you should probably not use it, as it is somewhat confusing what it means.
after finished the duration also one vuser is continuously running and the script is not finished from terminal. i saw in grafana that one vuser is continuously running after duration is finished
It is not that bug … and even if it was I don’t think there would’ve been a problem.
So after 8 minutes the script doesn’t stop. Does it print something ? If you kill it does it print some funky metrics at the end ? Although non of this … currently should be a problem. How long have you waited ?
after i kill the process it’s printing the metrics…i have waited almost 10-15 mins and still 1 user is running
You can try running with --debug and see if at the end there is no strange unexpected message and maybe pasting it here.
Other than that I am out of ideas 
. We will probably need the script in order to find what is wrong and it might not be just the script but a combination of things including the fact that you use influxdb that trigger this strange behavior. I am almost certain that this will be fixed by the arrival rate based execution PR as it rewrites big parts of code handling the actual stopping of k6, but still it would be good idea to find out what is making your script run forever.
If you don’t want to post your script for everybody maybe you will be fine to just send it to me ?
sure…thank you for all your inputs
The only think that I can think of that will block k6 forever is this. Maybe a similar problem can exist in other cases but all of them will be … fixed … or more accurately k6 will exit either way after PR#1007
Do you use Upgrade headers anywhere?
Does your script actually appear to work apart from it not exiting?
What happens if you just run it with 15 VUs for 15 iterations?
Have you tried old versions? We did some changes in the last two version on how we execute scripts, but no one has reported any problem and Load Impact does run … thousands of k6 instances each day all of them with stages, so I find it highly unlikely that this is not something to do with what your script does or some very strange corner case.
. We will probably need the script in order to find what is wrong and it might not be just the script but a combination of things including the fact that you use influxdb that trigger this strange behavior. I am almost certain that this will be fixed by the