headless ubuntu not syncing

Hey jainraje, sorry to hear you're having issues with this.

Can you please clarify if you've enabled the desktop app to auto-start when you boot your device as outlined here? 

Let me know and we'll take it from there. 

HI Walter,

Thank you for your message.

To summarize I installed the headless dropbox on a headless ubuntu 16.04 and confired a systemd service unit to run at system boot time (using my username as opposed to root). Finally, I enabled the auto-start at system boot as any other systemd service unit by issuing the following command: $sudo systemctl enable dropbox

My understanding is the above will setup the system to always run the dropboxd after system reboot. No manual intervention is required.

The dropbox.py (Dropbox Desktop App) and dropboxd work together yes?  

Every time I run dropbox status is always returns Dropbox isn't running yet some files appeared to sync correctly. So I'm really confused and do not feel confident the system is setup correctly. 

---

jainraje wrote:

...

Every time I run dropbox status is always returns Dropbox isn't running yet some files appeared to sync correctly. ...

---

Hi jainraje,

Did you make sure you have run 'dropbox status' under the same user context like the Dropbox daemon? Take in mind that every user can have independent Dropbox context and running the control script in one context targets the Dropbox daemon on the same context, not any other! 😉

Hope this helps.

I believe yes to your question.

Upon closer inspection is appears the daemon is having errors starting.

$sudo journalctl -u dropbox.service

systemd[1]: dropbox.service: Main process exited, code=killed, status=9/KILL

systemd[1]: dropbox.service: Unit entered failed state.

systemd[1]: dropbox.service: Failed with result 'signal'.

---

jainraje wrote:

I believe yes to your question.

...

---

Hm... 🤔... What's the meaning of 'believe' above? What's it actually?! That's the matter! What's getting back following:

ps axo user,comm | grep dropbox

Nothing comes back:

$ ps axo user,comm | grep dropbox

A few additional data points:
1) After a fresh reboot the dropbox systemd service unit fails during start-up:

$sudo journalctl -u dropbox.service

systemd[1]: Started Dropbox Daemon.
dropboxd[29288]: dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/cryptography.hazmat.bindings._openssl.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/cryptography.hazmat.bindings._padding.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/apex._apex.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/psutil._psutil_linux.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/psutil._psutil_posix.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/tornado.speedups.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/wrapt._wrappers.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/home/user/.dropbox-dist/dropbox-lnx.x86_64-164.4.7914/cryptography.hazmat.bindings._padding.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/home/user/.dropbox-dist/dropbox-lnx.x86_64-164.4.7914/apex._apex.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/home/user/.dropbox-dist/dropbox-lnx.x86_64-164.4.7914/psutil._psutil_linux.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/home/user/.dropbox-dist/dropbox-lnx.x86_64-164.4.7914/psutil._psutil_posix.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/home/user/.dropbox-dist/dropbox-lnx.x86_64-164.4.7914/cryptography.hazmat.bindings._openssl.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/home/user/.dropbox-dist/dropbox-lnx.x86_64-164.4.7914/tornado.speedups.cpython-38-x86_64-linux-gnu.so'
dropboxd[29288]: dropbox: load fq extension '/home/user/.dropbox-dist/dropbox-lnx.x86_64-164.4.7914/wrapt._wrappers.cpython-38-x86_64-linux-gnu.so'
systemd[1]: dropbox.service: Main process exited, code=killed, status=9/KILL
systemd[1]: dropbox.service: Unit entered failed state.
systemd[1]: dropbox.service: Failed with result 'signal'.
systemd[1]: dropbox.service: Service hold-off time over, scheduling restart.
systemd[1]: Stopped Dropbox Daemon.2) A dropbox process is running in memory:

2) A dropbox process is running in memory:
$top | grep dropbox
12229 user    20   0  398112  39552  20472 R 100.0  0.5   0:00.26 dropbox 

---

jainraje wrote:

Nothing comes back:

$ ps axo user,comm | grep dropbox

 

---

If nothing comes back (at that moment at least), no any Dropbox daemon is running. I cannot support your service setup. You should check what's going wrong there; it's not a Dropbox issue.

---

jainraje wrote:

...

...
2) A dropbox process is running in memory:
$top | grep dropbox
12229 user    20   0  398112  39552  20472 R 100.0  0.5   0:00.26 dropbox 

---

As seems, for some reason, it starts later. Why? 🧐 It's something you should figure out.

As can be seen the context is different! Now if you just run:

dropbox status

..., you will get "Dropbox isn't running!" for sure. Cosa it's so: there is not running Dropbox daemon in "rajeev" context; it's running in "user" context.

Your default context is rajeev, but you can switch to user using something like:

sudo -u user dropbox status

Now you will get the actual context (the user context). 😉

Good luck.

the `user` in the log was me removing my actual username. sorry that was misleading. there are only 2 contexts rajeev and root. i'm going to try to sort this out. i'm going to disable the dropbox systemd and run dropbox manually.  i'll keep this thread updated. any comments or suggestions from you or others are well received. again, many thanks for your messages. 

Update:

After disabling the dropbox systemd service unit and rebooting  no dropbox was running in memory according to `top`. I was then able to successfully run dropbox from the command-line. All desired file/folders are synching at this point.

Now that via the command-line dropbox is working correctly I'll focus my attention on getting dropbox to auto synch after system boot using the systemd service unit. i recall reading somewhere a delay is required to get that scheme to work. 

jainraje, I just took a look on your "guide" (if can be said so) and there are some conceptual bugs. Don't "install" the daemon on place different than described by Dropbox (something messed by your guide). That's the source of your issues. Better build your own service instead of using unreliable guides!