Dropbox freezes the poweroff process

Please post any bugs you have found
Post Reply
Message
Author
User avatar
Rattlehead
Posts: 368
Joined: Thu 11 Sep 2008, 11:40

Dropbox freezes the poweroff process

#1 Post by Rattlehead »

I am running Puppy 4.3.1. frugal. I was lucky installing the Dropbox portable app found here http://www.murga-linux.com/puppy/viewtopic.php?t=65624. It asked me to signup the first time, created a /root/Dropbox folder in my computer, and all well and running. :D

However, whenever Dropbox has been running, the computer seems to become disoriented during the shutdown process. Goes like this: first, it takes longer than normal before leaving X, and then it gets frozen in the black screen and the "Puppy is shutting down..." message, so I have to use the reset or poweroff buttons.

However, if I use the computer without running Dropbox, the reset and poweroff procedures go back to normal; so, obviously, it has something to do with Dropbox.

It doesn't even seem to matter if Dropbox is actually running while the shutdown takes place: if Dropbox has been executed at any point during the session, even if later it was stopped (by typing the command 'dropbox stop', or even killing all the dropbox processes), I get the same bug.

This bug behaves the same either if I run the Dropbox portable app manually or if I have it linked to /root/Startup for it to autostart (which it does flawlessly).

The bug also behaves the same either executing a poweroff ('wmpoweroff') or a reboot ('wmreboot').

I have also tried using different window managers and the bug acts the same.

I have also tried .pet versions of Dropbox (on a different, guinea pig pupsave), and none of them work.

I have also tried installing SpiderOak, the alternative service mentioned in the Dropbox thread, but it throws a verbose error about Internet certificates.

I have ran out of ideas, do you have any? Dropbox is really fast and handy and would really help my workflow...

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#2 Post by Karl Godt »

does dropbox mount internet shares ?

User avatar
Rattlehead
Posts: 368
Joined: Thu 11 Sep 2008, 11:40

#3 Post by Rattlehead »

does dropbox mount internet shares ?
I tried running the dropbox script while watching the /mnt folder at the same time, to see if any change happens, but not at all; nothing gets mounted, if that's what you meant by 'internet shares' (and if it isn't, could you elaborate a bit more? I'm no expert on the matter).

I then tried one more thing, which btw I wonder if it is related to mounting: I run the dropbox script from console, and here is the result:

Code: Select all

shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
The console thus created cannot be closed with ctrl+c or ctrl+d, only killing it. I tried moving the dropbox script to different locations and mounted partitions, and got in all the cases the same result. With one exception: when the script is inside the /root/Dropbox folder, you get the same erorr, but you do can interrupt it with ctrl+c, and here is what it produces:

Code: Select all

shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

^CTraceback (most recent call last):
  File "__main__dropbox__.py", line 23, in <module>
  File "client_api/dropbox_connection.py", line 21, in <module>
  File "common_util/functions.py", line 26, in <module>
  File "common_util/globals.py", line 1, in <module>
KeyboardInterrupt

Any idea?

User avatar
Rattlehead
Posts: 368
Joined: Thu 11 Sep 2008, 11:40

#4 Post by Rattlehead »

OK, I have new advances that shed some light.

When executed, the Dropbox script creates a mount point in /tmp. Its name is always different, under the format .mount_somerandomcharacters.

Any attempt to delete or unmount such mount point causes either a) computer frozen b)'Device is busy' error c)'Transport endpoint is not connected' d) the process related to the unmount attempt (either via Rox or the umount command...) freezes.

Even when you stop dropbox with the 'dropbox stop' command, the mount point remains active.

The best result so far is that, when d) happens, once you kill the frozen processes via pprocess, it throws an error but the mountpoint finally disappears, and you can close the computer normally.

I guess during poweroff, Puppy tries to unmount it or simply clean the /tmp folder, and it enters an infinite wait due to that 'ghost mount point'.

Maybe it is a security issue, something related to Puppy running as root? Any inspiration out there, please? Could I force the unmounting somehow? Should I?

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#5 Post by Karl Godt »

I have submitted some suggestions/patches to /etc/rc.d/rc.shutdown script, that's what does all the tidy up at shutdown . There had been also accepted suggestions in the bug section by forum member idolse i think regarding network shares .

It seems
a) the dropbox script cd into a directory and deletes it without cd out of it before .
so this is kind of bug there which normally doesn't matter,
have experienced it myself with one of my private adjustments to the package manager script once .

b) BK recently posted on his blog "Do not delete /tmp/* at shutdown" http://bkhome.org/blog/?viewDetailed=02789 so only the most recent Woof based Puppies might have it .

c) Yes, rc.shutdown unmounts everything .

d) Yes, such network shares i meant .

combined lead to your troubles .

Would not really have expected the mount point in the /tmp directory either .

Puppy is cut down so dropbox probably is using a busybox applet instead of an expected binary here and there but still seems to access your network share in the dropbox cloud . Whatever happens when not logged out there i don't know .

Dropbox seems to consist of a huge amount of python scripts and python support is usually not one of Puppies' strengths .

User avatar
Rattlehead
Posts: 368
Joined: Thu 11 Sep 2008, 11:40

#6 Post by Rattlehead »

Thank you for all the useful hints you provide. I'm still processing part of the information, but here are some things I've tried so far:

-Just in case, I ran a 4.3.1. live CD and executed Dropbox, to discard some clutter in the pupsave. The error acted just the same.

-Following the link to BK's blog, I tried commenting the line that deletes /tmp in the rc.shutdown script. But the error remains the same.

-I ran Lupu (which is woof-based, isn't it?), extracted its rc.shutdown script, and copied it into my 4.3.1. installation (creating a backup of my rc.shutdown first, of course), to check any change in shutdown behavior. No change at all.

-
the dropbox script cd into a directory and deletes it without cd out of it before
Executing 'type dropbox' prompts /usr/bin/dropbox, which turns to be a python script that can be edited. I don't know a word of python, but I revised the script in case the comments indicated a self-evident way to to make the required directory change. But I couldn't get a hold of it. Maybe some forum member who knows python can help?

-
dropbox probably is using a busybox applet
Don't know if exactly related, but the processes that get frozen when I try to unmount dropbox's 'ghost directory' are like this:

Code: Select all

/bin/sh /bin/umount -i /tmp/.mount_whatevercharacters -l
[b]busybox[/b] umount -d -i /tmp/.mount_whatevercharacters -l
So I tried to unmount using the umount-FULL command instead, because I guess it is not included in busybox. The error happened just the same.

-
Dropbox seems to consist of a huge amount of python scripts and python support is usually not one of Puppies' strengths .
One question here: is Puppy's python version abridged, like it happens with bash? If so, would it be of any good to install a full version somehow?

Now I'm trying to get my head around your modifications of rc.shutdown and Idolse's thread. Thank you for all the suggestions.

User avatar
Rattlehead
Posts: 368
Joined: Thu 11 Sep 2008, 11:40

#7 Post by Rattlehead »

OK, so could not make head or tails of any of the threads. :roll:
I use Linux because I love freedom, but I've come to terms with the evidence that I'll never be the geek of the year.
In the meantime, I've discovered wuala, a feasible alternative (it uses Java, which is bloated, but... well, it works).
Thank you anyway. If someone is looking for options for cloud hosting, this thread here was very useful for me:

http://www.murga-linux.com/puppy/viewtopic.php?t=64309

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#8 Post by Karl Godt »

There might be a bug with fusermount -u that calls /bin/umount again a second time.

Also the ps line to grep 'ntfs\-3g' does not work for me if i set PS_PERONALITY to something other than the default .

User avatar
Rattlehead
Posts: 368
Joined: Thu 11 Sep 2008, 11:40

#9 Post by Rattlehead »

Thank you, those are great lines of investigation if one day I decide to try Dropbox again. By the moment, I'm going to settle with Wuala. It has a 'synchronization mode' where you can choose which folders you want copied, and when I get to know it a bit better, there is a also command-line mode, using which I can crank a couple of scripts to make it totally dropbox-like. :)

Post Reply