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

ioc destroy -f should call ioc stop -f #732

Open
igalic opened this issue May 12, 2019 · 3 comments
Open

ioc destroy -f should call ioc stop -f #732

igalic opened this issue May 12, 2019 · 3 comments

Comments

@igalic
Copy link
Collaborator

igalic commented May 12, 2019

root@webserver /u/l/s/i/.libioc# ioc destroy -f blog
[-] ZFSDatasetDestroy@zroot/ioc/jails/blog: ...
Traceback (most recent call last):
  File "/usr/local/bin/ioc", line 10, in <module>
    sys.dd:exit(cli())
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/ioc_cli/destroy.py", line 125, in cli
    ctx.parent.print_events(item.destroy())
  File "/usr/local/lib/python3.6/site-packages/ioc_cli/__init__.py", line 91, in print_events
    for event in generator:
  File "/usr/local/src/ioc/.libioc/libioc/Jail.py", line 1177, in destroy
    raise e
  File "/usr/local/src/ioc/.libioc/libioc/Jail.py", line 1174, in destroy
    self.zfs.delete_dataset_recursive(self.dataset)
  File "/usr/local/src/ioc/.libioc/libioc/ZFS.py", line 96, in delete_dataset_recursive
    self.delete_dataset_recursive(child)
  File "/usr/local/src/ioc/.libioc/libioc/ZFS.py", line 101, in delete_dataset_recursive
    dataset.umount()
  File "libzfs.pyx", line 2547, in libzfs.ZFSDataset.umount
libzfs.ZFSException: Device busy
root@webserver /u/l/s/i/.libioc#

now let's call stop -f, the destroy -f again:

root@webserver /u/l/s/i/.libioc# ioc stop -f blog
[+] JailStop@blog: OK [0.096s]
  [+] JailHookPrestop@blog: SKIPPED [0.001s]
  [+] JailHookStop@blog: not running [0.0s]
  [+] JailRemove@blog: SKIPPED [0.001s]
  [+] JailHookPoststop@blog: SKIPPED [0.001s]
  [+] MountFstab@blog: OK [0.001s]
  [+] BasejailStorageConfig@blog: OK [0.019s]
  [+] TeardownSystemMounts@blog: OK [0.002s]
  [+] JailResourceLimitAction@blog: SKIPPED [0.001s]
blog stopped
root@webserver /u/l/s/i/.libioc# ioc destroy -f blog
[+] ZFSDatasetDestroy@zroot/ioc/jails/blog: OK [0.1s]
/iocage/jails/blog destroyed
root@webserver /u/l/s/i/.libioc#

works. imo, destroy -f should work the same.

@urosgruber
Copy link
Contributor

Agree, this would ease thing a bit.

@gronke
Copy link
Member

gronke commented Jun 4, 2019

@igalic to reproduce your case, the jail must have failed being stopped manually (without force). This means that the JID has been already removed, but the poststop task did not succeed.

I wonder if it would make sense to always force stop and remove the option to stop without that behavior. libioc without a daemon is stateless and we should never have jails in zombie state.

If that becomes the only way to stop, the problem raised in this Issue, would also disappear. What do you say?

@igalic
Copy link
Collaborator Author

igalic commented Aug 9, 2019

either that, or we could make stop without -f block until it's done

of course that could hang "forever"
so it would be nice if it was cancellable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants