You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Dropbox is looking for deprecated package
Every time when I run Dropbox next message appear
'python-gpgme' package was interface to the gpgme before Ubuntu 17.10. From Ubuntu 17.10 (up to present) 'python-gpgme' is deprecated in favor of 'python-gpg' ('python3-gpg' for python 3). Currently 'python-gpgme' is no more in Ubuntu repositories!
Probably this is small mistake (forgotten package name) need to be corrected. Everything else works. Please forward the bug note to your technical team. This dummy message is really annoying and the checkbox 'Don't show this again' don't work.
Thanks in advance.
Rich wrote:Have you opened a ticket with Support?
Hi Rich,
I suppose this have to be the funny part... :grinning:
Just example of such ticket can be seen here. In this context, what I can rely on?! It's the same - here (in the forum with 'a few Dropboxers') or through a ticket. Very often users meet the same problem and can give more valuable advice. That's why I prefer to write here. In this thread I ask for technical support, not PR. If someone from the Dropboxers want, can forward all this to technical team (or at least the bug description). If not, ... :unamused:
Anyway... Thanks for Your advice! I appreciate Your try to help.
I found a workaround (until the moment, if any, when this bug become fixed). Just introducing delay in running process, so more system resources are available and triggering the bug become less likely (in my case, till the moment, didn't happen). I implement this using a script like:
#!/bin/bash sleep XXX /usr/bin/dropbox $@
Where 'XXX' is carefully selected delay (in seconds), so heavy load time span to be jump over. It works for me. If someone else meet same problem can try this.
Ooo... I found out what's wrong.
My dropbox installer package wasn't up to date. In the latest one this seems fixed.
In this context one next question: Why two package management systems have to be used? One for the installer (and runner) - the system one and another for the application managed by self. Isn't possible only one to be used? So (using single package) no version mistake could be possible (or less probable at least). My preference is - system management. Would be possible such thing to happen someday?
No exactly fixed!
Yes, There is no more "Note" for deprecated package, but from time to time message asking me to "download the proprietary daemon" still appear:
Both the installer package and the application are up to date (2019.02.14 and v69.4.102 accordingly). This dummy message is generated from installer package and not always, but from time to time. Any idea why this happens? And again, the previous question, why one application need two part from two completely different repositories? (The message erroneous ask for fetching application part from the second repository!!! This is already done before!)
Like in many other cases, seems nobody can say anything (from Dropbox side)!
I think, It's stupid decision to conclude that dropbox isn't installed if there is some problem running it (even erroneously detected problem). I mean the code near line 1440 in 'dropbox':
if not start_dropbox(): if not should_install: console_print() console_print("The Dropbox daemon is not installed!") console_print("Run \"dropbox start -i\" to install the daemon") return # install dropbox!!! try: download() except: traceback.print_exc()From other view point, in 'start_dropbox' function, near line 760 in the same file:
# in seconds interval = 0.5 wait_for = 60 for _ in range(int(wait_for / interval)): if is_dropbox_running(): return True # back off from connect for a while time.sleep(interval) return FalseCan be seen that decision for successful running depends on 'is_dropbox_running' function result. This function result from other side depends on matching pid, set on time in '~/.dropbox/dropbox.pid', as can be seen near line 140 in the same file:
def is_dropbox_running(): pidfile = os.path.expanduser("~/.dropbox/dropbox.pid") try: with open(pidfile, "r") as f: pid = int(f.read()) with open("/proc/%d/cmdline" % pid, "r") as f: cmdline = f.read().lower() except: cmdline = "" return "dropbox" in cmdlineAnd here is the place where the problem comes from. On heavy loaded system, during initial login, many other services can query for processor time and disk access simultaneously, together with Dropbox! Additionally open web browser left from previous session, carrying few tenths of pages, and other similar applications can query together system resources. In such a situation setting correct pid can take some time. During all this time 'is_dropbox_running' function will think that the Dropbox is NOT running, even while it really runs (or at least going to, without totally finished initialization still)! The 'start_dropbox' function assumes the same, next some timeout. And finally, as result, follows stupid conclusion that Dropbox is not installed (erroneous)! The same erroneous conclusion (and initiating install action) could be triggered by virtually any runtime error in the daemon, during initialization (even incident one, non related in any way to the installation process)!
The easiest and fastest workaround is timeout set to be increased (for example doubled). Of course such action is definitely not a solution because there is no exact answer "How much?"! Real solution would be the chain of assumptions break. Wich mean restructuring the code and write it without assumption that something is, if there could be opposite situation (even when such situation seems not likely). If You don't follow above rule lead to error prone code (error - including race conditions and not only).
Again, please forward this to your technical team. I hope it will help improving Your code.
