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.

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

Single Ctrl+C is not enough to cancel az resource group delete #596

Closed
ahmetb opened this issue Aug 2, 2016 · 7 comments
Closed

Single Ctrl+C is not enough to cancel az resource group delete #596

ahmetb opened this issue Aug 2, 2016 · 7 comments
Assignees
Labels
ARM az resource/group/lock/tag/deployment/policy/managementapp/account management-group bug This issue requires a change to an existing behavior in the product in order to be resolved. Resource Manager
Milestone

Comments

@ahmetb
Copy link
Contributor

ahmetb commented Aug 2, 2016

# az resource group delete -n docker-machine
Starting resource group delete
^CTraceback (most recent call last):
  File "/usr/local/lib/python3.5/runpy.py", line 184, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/lib/python3.5/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/local/lib/python3.5/site-packages/azure/cli/__main__.py", line 29, in <module>
    sys.exit(azure.cli.main.main(args))
  File "/usr/local/lib/python3.5/site-packages/azure/cli/main.py", line 55, in main
    cmd_result = APPLICATION.execute(args)
  File "/usr/local/lib/python3.5/site-packages/azure/cli/application.py", line 117, in execute
    result = expanded_arg.func(params)
  File "/usr/local/lib/python3.5/site-packages/azure/cli/commands/__init__.py", line 219, in _execute_command
    return LongRunningOperation('Starting {}'.format(name))(result)
  File "/usr/local/lib/python3.5/site-packages/azure/cli/commands/__init__.py", line 96, in __call__
    self._delay()
  File "/usr/local/lib/python3.5/site-packages/azure/cli/commands/__init__.py", line 89, in _delay
    time.sleep(self.poll_interval_ms / 1000.0)
KeyboardInterrupt

the process keeps running after I hit Ctrl+C once... It finally quits when I hit it twice:

^CException ignored in: <module 'threading' from '/usr/local/lib/python3.5/threading.py'>
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/threading.py", line 1288, in _shutdown
    t.join()
  File "/usr/local/lib/python3.5/threading.py", line 1054, in join
    self._wait_for_tstate_lock()
  File "/usr/local/lib/python3.5/threading.py", line 1070, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt
@JasonRShaver JasonRShaver added this to the Backlog milestone Aug 3, 2016
@JasonRShaver JasonRShaver added the bug This issue requires a change to an existing behavior in the product in order to be resolved. label Aug 3, 2016
@mayurid mayurid modified the milestones: Sprint 2, Backlog Aug 24, 2016
@tjprescott
Copy link
Member

@ahmetalpbalkan which shell were you using? When I try this in CMD, it doesn't really matter if I press once or twice, I'm at the mercy of the LRO poller for a while. Is this your experience as well?

@ahmetb
Copy link
Contributor Author

ahmetb commented Aug 25, 2016

@tjprescott I use zsh via oh-my-zsh on OS X. I hit Ctrl+C once, waited like 10 seconds, nothing happened and I went ahead by hitting Ctrl+C again.

It shouldn't matter where you are in the program. Hitting Ctrl+C once is supposed to exit the program, right?

@tjprescott
Copy link
Member

@ahmetalpbalkan yes. What is happening is the first Ctrl+C is terminating the CLI, but because you initiated a LRO to delete the resource group, the second terminates that thread. I've confirmed it does the behavior you describe in bash as well. (CMD makes you wait even after the second Ctrl+C).

Out of curiosity, is the reason you are pressing Ctrl+C because you don't want to wait for the resource group delete operation to finish? You just want to "fire and forget"?

@ahmetb
Copy link
Contributor Author

ahmetb commented Aug 25, 2016

@tjprescott

What is happening is the first Ctrl+C is terminating the CLI, but because you initiated a LRO to delete the resource group, the second terminates that thread. I've

got it but I don't think any of your users will care about this

is the reason you are pressing Ctrl+C because you don't want to wait for the resource group delete operation to finish? You just want to "fire and forget"?

exactly. since I mostly do manual management of RGs I just want backend API to continue deleting in the background, so I just keep it around for like 3 seconds. I use az[ure] resource group delete like this all the time.

@tjprescott
Copy link
Member

@mayurid moving this to the backlog. PR #757 has been open which would create a workaround solution for the CLI. However Azure/autorest#1379 addresses this at the autorest level but has not been approved yet.

@tjprescott tjprescott modified the milestones: Backlog, Sprint 2 Sep 6, 2016
@mayurid
Copy link
Member

mayurid commented Sep 6, 2016

@tjprescott: will work with the Autorest guys to get the fix expedited.

@derekbekoe
Copy link
Member

Fixed with msrestazure 0.4.3 so closing issue.
see #757 (comment)

@mozehgir mozehgir added the ARM az resource/group/lock/tag/deployment/policy/managementapp/account management-group label Aug 14, 2019
@haroldrandom haroldrandom added bug This issue requires a change to an existing behavior in the product in order to be resolved. Resource Manager labels Oct 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ARM az resource/group/lock/tag/deployment/policy/managementapp/account management-group bug This issue requires a change to an existing behavior in the product in order to be resolved. Resource Manager
Projects
None yet
Development

No branches or pull requests

7 participants