-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Revert "fix ugly error message when killing commands" #1081
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
Revert "fix ugly error message when killing commands" #1081
Conversation
@whyrusleeping any 💭 ? |
This reverts commit f74e71f. The 'Online' flag of the command context does not seem to be set in any code paths, at least not when running commands such as 'ipfs daemon' or 'ipfs ping'. The result after f74e71f is that we never shutdown cleanly, as we'll always os.Exit(0) from the interrupt handler. The os.Exit(0) itself is also dubious, as conceptually the interrupt handler should ask whatever is stalling to stop stalling, so that main() can return like normal. Exiting with -1 in error cases where the interrupt handler is unable to stop the stall is fine, but the normal case of interrupting cleanly should exit through main().
7a0169f
to
17cfa53
Compare
@torarnv may want to just add the other commits fixing the original error in this same PR. |
@jbenet okey, did that |
Oh, you mean't fixing the "file "/Users/torarne/.go-ipfs/daemon.lock" already locked" stuff on top here |
@torarnv I just realized how wrong i was with that commit. My apologies for committing crappy code (daemon shutdown will never properly close a profile the way it is now) |
@whyrusleeping Don't worry about it man! I was just a bit confused and wondering if I missed something obvious when trying to understand the logic 😃 |
I'll do this as part of #1037 instead |
This reverts commit f74e71f.
The 'Online' flag of the command context does not seem to be set in
any code paths, at least not when running commands such as 'ipfs daemon'
or 'ipfs ping'. The result after f74e71f is that we never shutdown
cleanly, as we'll always os.Exit(0) from the interrupt handler.
The os.Exit(0) itself is also dubious, as conceptually the interrupt
handler should ask whatever is stalling to stop stalling, so that
main() can return like normal. Exiting with -1 in error cases where
the interrupt handler is unable to stop the stall is fine, but the
normal case of interrupting cleanly should exit through main().