Child Item

Linux client hangs in futex() call during startup

The Dropbox Linux client is hanging during startup on my Red Hat Enterprise Linux (RHEL) 6 box. It has worked on this machine before, and unfortunately I don't know what changed now. I have tried wiping out my "~/.dropbox" and "~/.dropbox-dist" directories, and using a fresh download of the client, but the hang persists. The same problem appears using both the 3.0.3 stable build as well as the 3.1.261 experimental build.

Tracing with "strace" reveals that the hang is in a call to "futex(0x295b1e0, FUTEX_WAIT_PRIVATE, 0, NULL)". Attaching a debugger to the hung process shows that we are down in some Python code. Most of the stack frames are either "PyEval_EvalCodeEx()" or "PyEval_EvalFrameEx()". The innermost stack frame is "sem_wait()", called from "PyThread_acquire_lock()".

I'm at a loss how to work around this or debug it further. Any suggestions as to how I can get my Dropbox client back up and running?

Find more posts tagged with

Setting Up the Apps

Desktop

Spam

Insightful

Comments

Chris S.

Add centos 6.5 to the list of those OS' having problems... I've tried creating new local accounts and it still gets stuck in the same place. In the new empty accounts, it doesn't even launch the GUI that asks the account questions. It creates several files in .dropbox, including a log file which I can't read (really useful guys...), then freezes. Even with dropbox running, the dropbox.py status returns that it isn't running. This worked a week ago, and I changed nothing.

Bjørn T.

Same problem on Arch Linux as of today. I upgraded Dropbox to v3.0.3 and it didnt solve the problem.

Dropbox hangs so badly that I cant even log in to the system. I get a 60 second login timeout. I had to disable the network connection, log in and disable the dropbox service to be able to access the system. There's a bunch of files being created in .dropbox/logs but they're not in plaintext and therefore unreadable.

Geert J.

I have the same problem with 3.0.3 on Centos 6.5. I suspect that an old version was silently updated.

My solution is to revert back to 2.10.30 and then make the .dropbox-dist directory read-only to avoid

automatic updates (which will happen!).

Ben L.

I'd like to try reverting to an earlier client version, per Geert J.'s suggestion. But where can I find that? Does anyone have a download link for older releases?

Magnus W.

The answer to your problems is here: https://www.dropboxforum.com/hc/communities/public/questions/201277199-Linux-version-keeps-updating-to-3-0-3-which-can-not-work

Read the first reply by user Tobias C.

Ben L.

Magnus W.'s pointer helped me recreate Geert J.'s workaround, which is working for me too. It's not a real fix, of course, but at least I have some Dropbox client back up and running again. Thank you, Magnus W. and Geert J.!

tim c.7

This appears to be the same problem as that reported in https://www.dropboxforum.com/hc/communities/public/questions/201559405-Dropbox-3-x-doesn-t-work-on-CentOS-6-5-but-2-x-does- with a number of followups and a possibly simpler way of installing 2.10 and prevent it being updated to fix the problem.

I see the problem in Fedora Core 10 (32 bit) - and I've just tried dropbox version 3.2.9 - unfortunately the fault is still there, same symptoms and an strace reveals it to be apparently the same place. I hope it gets fixed before 2.10 gets locked out, otherwise there'll be no way of running dropbox for anyone with what appears to be significant list of linux distros

Eric S.

This seems to be caused by running too old of a version of glib. We depend on at least version 2.22. This dependency version change was caused by the switch from Gtk to Qt. I suggest upgrading to a newer version of your distro.

If that's not an option, the headless Dropbox client might work. Just launch Dropbox with:

DISPLAY= ~/.dropbox-dist/dropboxd

You can then use dropbox.py to control the headless client.

Hannu V.

I seem to be having the same issue on Fedora 21 on one of my machines. After dropbox startup, the machine seems to slow down further and further, until the only thing that helps is to kill dropbox. The odd thing is that the process is eating hardly any CPU at all and I haven't perceived any IO waits either when this happens.

One other noteworthy oddity is that it only happens on one of my Fedora 21 machines, the rest of them are unaffected and work just fine with the same dropbox account/version.

Andrew S.51

I'm having this problem too and I'm unable to use Dropbox client unless I run a command-line version of it (with DISPLAY unset). This is a plain Ubuntu Vivid with no significant changes from the upstream.

Andrew S.51

Also, I've got libglib2.0-0=2.44.1.

Sven U.1

I had success after scanning for missing library dependencies of the Dropbox distribution. Basically you can run something like this:

LD_LIBRARY_PATH=~/.dropbox-dist/dropbox-lnx.x86_64-3.8.8/ ldd ~/.dropbox-dist/dropbox-lnx.x86_64-3.8.8/* 2>/dev/null|grep "not found"

Change the distribution path to match yours. In my case, the shipped libQt5WebKit.so.5 and libQt5WebKitWidgets.so.5 libraries depended on libxslt.so.1, which is not included in the Dropbox distribution. After installing it on my Debian Jessie system (package "libxslt1.1"), everything was working right away.

Dropbox distribution version: 3.8.8; Debian "dropbox" package (installer) version: 2015.02.12.

I have requested that the Debian "dropbox" package on linux.dropbox.com/debian/ is changed to depend on the "libxslt1.1" package to fix that particular problem.

Andrew S.51

Sven, thanks for your hint; I have to say I do have libxslt1.1 installed, and the output of a similar command it empty on my system.

[This thread is now closed by moderators due to inactivity. If you're experiencing a similar behavior, feel free to start a new discussion in the Ask a Question section here.]