We're running a dropbpox instance on a debian server in headless mode. We used the instructions here and the python script to control it.
Recently the server ran out of disc space. Upon investigation we found that the Dropbox cache tmp_dirs was full of dozens and dozens of dropbox-upgrade-96.4.172.tar.gz.
It appears that Dropbox was trying to auto update itself, and that update was failing due to a missing dependency.
I'd like to suggest that Dropbox only needs to download the upgrade file once, not each time it tries to update itself. Check the cache and see if it is already there. Lacking that, at least clean up after yoursel if the update fails. Using all that bandwidth to redownload the file is not ideal, but running the server out of disc space is even less ideal.
I'm complety unlable to find any kind of log that Dropbox might be writing to which I could have monitored and been alerted that an upgrade failed. I can't even find any way to get it from stdin or stderr. Manually trying to trigger an upgrade creates no output that I can find.
Hi there @navaho99, thanks for checking in with us.
Just to make sure that we cover as much initial troubleshooting as possible, could you first confirm if your setup meets the Dropbox app's essential requirements for Linux OSes, which are necessary for headless installations?
user@servername:~# uname -a
Linux servername 5.4.10-x86_64-linode132 #1 SMP PREEMPT Thu Jan 9 21:17:12 UTC 2020 x86_64 GNU/Linux
Glibc is 2.50
user@servername:~# dpkg -l | grep glib
ii libglib2.0-0:amd64 2.50.3-2+deb9u2 amd64 GLib library of C routines
ii libglib2.0-data 2.50.3-2+deb9u2 all Common files for GLib library
Dropbox app was the latest when installed via the instructions quoted above. This appears to be Nov 22 last year.
To be clear, Dropbox was running fine. That's not the issue. The issue is that the upgrade failed due to missing dependencies (libglapi-mesa and libxdamage1), did not alert us to same, and then continued to download the update file over, and over, and over, and.... you get the picture.
All I am saying is that Dropbpx should clean up after a failed update and give us a way to redirect a log file so that we can know what Dropbox is doing. This is especially critical in a headless environment.
Re: headless autoupgrade ran server out of disc space.