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.

Sign up for GitHub

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

Jump to bottom

[minor] "~/.go-ipfs/daemon.lock" already locked #1053

Closed
okket opened this issue Apr 11, 2015 · 2 comments
Closed

[minor] "~/.go-ipfs/daemon.lock" already locked #1053

okket opened this issue Apr 11, 2015 · 2 comments
Labels
kind/bug A bug in existing code (including security flaws) topic/commands Topic commands

Comments

@okket
Copy link

okket commented Apr 11, 2015

Currently, when stopping a running command like ipfs ping with Ctrl-C the client tries to open the repository on close, resulting in the confusing, bogus message:

ERROR   cmd/ipfs: file "~/.go-ipfs/daemon.lock" already locked <autogenerated>:24
Received interrupt signal, shutting down...

This does not cause any issues other than giving ipfs a bad UX rep ;)
@whyrusleeping whyrusleeping added kind/bug A bug in existing code (including security flaws) topic/commands Topic commands labels Apr 11, 2015
@whyrusleeping whyrusleeping mentioned this issue Apr 12, 2015
Merged
@whyrusleeping
Copy link
Member

fixed!

@jbenet
Copy link
Member

jbenet commented Apr 13, 2015

thanks @okket -- these sorts of things are really important. our UX should be great.

torarnv added a commit to torarnv/go-ipfs that referenced this issue Apr 17, 2015
@torarnv
Handle ipfs command interruption by cancelling the command context
796ba77 
Instead of assuming the command is the daemon command and closing
the node, which resulted in bugs like ipfs#1053, we cancel the context
and let the context children detect the cancellation and gracefully
clean up after themselves.

The shutdown logging has been moved into the daemon command, where
it makes more sense, so that commands like ping will not print out
the same output on cancellation.
torarnv added a commit to torarnv/go-ipfs that referenced this issue Apr 17, 2015
@torarnv
Handle ipfs command interruption by cancelling the command context
d786383 
Instead of assuming the command is the daemon command and closing
the node, which resulted in bugs like ipfs#1053, we cancel the context
and let the context children detect the cancellation and gracefully
clean up after themselves.

The shutdown logging has been moved into the daemon command, where
it makes more sense, so that commands like ping will not print out
the same output on cancellation.
torarnv added a commit to torarnv/go-ipfs that referenced this issue Apr 17, 2015
@torarnv
Handle ipfs command interruption by cancelling the command context
158adff 
Instead of assuming the command is the daemon command and closing
the node, which resulted in bugs like ipfs#1053, we cancel the context
and let the context children detect the cancellation and gracefully
clean up after themselves.

The shutdown logging has been moved into the daemon command, where
it makes more sense, so that commands like ping will not print out
the same output on cancellation.
torarnv added a commit to torarnv/go-ipfs that referenced this issue Apr 20, 2015
@torarnv
Handle ipfs command interruption by cancelling the command context
cf6a268 
Instead of assuming the command is the daemon command and closing
the node, which resulted in bugs like ipfs#1053, we cancel the context
and let the context children detect the cancellation and gracefully
clean up after themselves.

The shutdown logging has been moved into the daemon command, where
it makes more sense, so that commands like ping will not print out
the same output on cancellation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/bug A bug in existing code (including security flaws) topic/commands Topic commands
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jbenet @okket @whyrusleeping