I have this issue on some of my machines.
I log out and discover after logging in days later that Dropox isn't running. There are no errors, no crashes, no messages. It's just not there.
The best I can figure is that it is Dropbox Updater that does it, because it is the only event that I can find. "Service Started" and "service stopped". Every time I come back Dropbox works out of the box, I can only assume that update runs, it's just never started again. There are folders that are in \dropbox\client\[version] that was last made yesterday, so updater ran.
Last change from that machine is March 20, 8:51 PM (no guarantee that was the last change - just last to sync). Last downloaded version by the updater was 93.4.273, dated on disk at March 20, 21:05. You see why I suspect the updater.
Event log shows a Dropbox cycle at the stated date:
* DBUpdate - Service started
* Signature verified
* Certificate Matched
* Accepting Connections from <exename>
* Unloaded driver
* Error: Failed to get driver message (-2147024890) - Is that -6?
* Error: Failed to connect, system cannot find file specified. Retrying... (was that a named pipe?)
* Signature verified
* Certificate Matched
* Pipe server thread stopped.
* Service stopped
* Service started
* Failed to connect
* Pipe server thread started.
* [dbupdate] service stopped
* [dbupdatem] service stopped
Every few hours, dbupdate starts and stops, but never attempts to restart the client again.
I have noticed that the machine most affected by this is a headless machine I only access remotely, whereas the other machines work well.
Erm, help? I mean, I could just schedule a task but that feels like a very bad idea if I ever want to do anything in peace like update data without my fiddling replicating.
I would like to add to this report that the machine is critical and "just reboot" or "just update Windows" isn't really an option for me. In fact, I am seriously considering abandoning the job rather than go there and touch the machine.
Is there a detailed log? I can't find one.
Hey @simpson b. , thanks for reaching out.
I don’t think that there’s a log within our app that I can point you to, unfortunately. What operating system is this machine running? How long has this been going on?
Let me know.
> What operating system is this machine running?
W10. May or may not be up to date. (it isn't, like I said I ideally reboot never.)
> How long has this been going on?
Definitely since I installed the machine. Before this it had a format because the old machine had a hardware failure. It used to do this back then, too. This machine has had this issue for ... years?
What is different about this machine in particular (that I can think of):
a) It is a Xeon workstation
b) It is headless
c) it is not up to date
a) Xeon workstation
I have had this issue before, and it wasn't a Xeon. I don't think this is an issue. I'm listing though.
Possible links: Xeon workstations I worked on are generally older, it may be a driver that is from, like, 2010. They tend to have obscure proprietary drivers.
Well, this is a thing. Every time I log in remotely, I log in and create a desktop, and if the machine has booted and has had no login, that COULD be a factor since Dropbox is an application. However, the machine never reboots.
Maybe the update process uses a mechanism that fails when nobody is logged in? An API or a UI thing that doesn't execute? A task scheduler task that doesn't run because there is nobody logged in?
c) System isn't up to date
I very much doubt this is a thing. I'd more expect this to be an issue if the app crashed but if it did the OS would log an error. In fact, it has NOTHING in any log which seems to point out that the executable exited politely.
I had this issue a long time ago on a system at the same location (I do tech support for a very tech illiterate company) and since it wasn't a dedicated machine I just assumed someone exited the client. It wasn't a Xeon and it WAS up to date, but as I was typing this I realized that back then they were using RDP and using a PC lock.
It might be that running the updater on a machine that has no user logged in fails. If an application uses a task schedule or some sort of call that includes an implied "logged on user" then that call could fail. And DB seems to be using services, the only way to launch something on my desktop would be to use "currently logged on user" or "current desktop" which might be inexistent.
Food for thought.
Hi @simpson b.,
Real reason is the combination of b) and the fact that you use Windows!
Let a working user session continuously.
Kill the updater and make updates from time to time by hand (when you login there).
Switch to Linux, where headless install is supported.
Could be enumerated many others, similar. Make the right choice for you.
Hey again, @simpson b..
It seems that there some factors in play here that could be causing the issue. The machine’s operating system is not being updated, for one. Another is the fact that you’re accessing remotely.
Normally, if our app is crashing, our support team will take you through some troubleshooting steps, and help investigate. If you don’t have direct access to this machine, I don’t believe that our team will be able to assist.
If you’d like to have one of our support agents have a look from our end, let me know, and I’ll have an agent email you at the address associated with your profile.
Hi again, @simpson b..
What I suggested is that if you’re accessing the machine remotely, we may not be able to help troubleshoot.
Alternatively, I can have an agent reach out to you at the email address associated with your profile.
Let me know!
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.Sound good? Let's get started.