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

how do I stop it? #468

Closed
themaddoctor opened this issue Jul 22, 2018 · 4 comments
Closed

how do I stop it? #468

themaddoctor opened this issue Jul 22, 2018 · 4 comments

Comments

@themaddoctor
Copy link

Several read and ls and rm processes are hung. I killed the terminal sessions to which they belong, but those processes are still running. I have tried every kill signal available, from user and from root, but they will not stop. I cannot unmount the google drive while these processes are running. I cannot kill goog-drive-ocamlfuse either.

@refi64
Copy link

refi64 commented Jul 22, 2018

If sudo pkill -KILL google-drive-ocamlfuse isn't working, you have problems in your system elsewhere. You could also try fusermount -u directory-you-mounted.

@Nate872711
Copy link

try "fusermount -zu /locationofmount"

@rhogenson
Copy link

I believe I am experiencing the same issue. I have google-drive-ocamlfuse installed from the beta PPA.

The issue can be reliably reproduced by running
truncate -s 50G ~/drive/test, which I would expect to take a while, it's uploading 50 gigabytes after all, but what I don't expect is I can't kill the truncate process, I can't kill google-drive-ocamlfuse while it's hung. Of course, I can't unmount either.

And note the problem doesn't just occur when I truncate files, random processes get hung as OP describes, but truncate is the most reliable way I've found to demonstrate the issue. Let me know if you want logs.

@astrada
Copy link
Owner

astrada commented Nov 15, 2018

You can kill the process anyway using kill -9. The mount point will be left in an error state, so you will have to unmount it with fusermount -u. The problem is that uploading begins when files are closed/released, and in a local file-system, that operation should be very quick. In a previous version the upload process was handled asynchronously but that increased the probability of having data inconsistencies server side.

@astrada astrada closed this as completed Nov 21, 2018
astrada added a commit that referenced this issue Jun 23, 2019
In background mode, the thread that flushed the memory DB
couldn't be joined because it started before the filesystem
initialization.
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

5 participants