Jump to content
  • 0

[.870] Always recovering after reboot


JohnKimble

Question

Been using .870 for a while not and never had issues with it. But it has come to light everytime in the midst of an upload and when I need to restart Clouddrive re-uploads my entire cache (50gb)+ the data is was moving... is this normal? Now I checked again and it seems to perform a recovery when the application restarts after rebooting the system like it was just "ungracefully shutdown" by Windows instead of waiting for Clouddrive to close down first. Is there anyway to fix this?

Link to comment
Share on other sites

20 answers to this question

Recommended Posts

  • 0

Nope.  

When rebooting, it should not do this.  It should pick up where it left off and continue. 

 

If it's re-uploading the entire cache, it's running a verification due to an unsafe shutdown of the service.  That means that something is definitely going wrong. 

 

If you could, enable tracing, and shutdown the system. 

http://wiki.covecube.com/StableBit_CloudDrive_Drive_Tracing

 

Don't worry about uploading... because after doing that, run the StableBit Troubleshooter (which will upload everything). 

http://dl.covecube.com/Troubleshooter/StableBit.Troubleshooter.exe

 

Make sure you submit "all", and check "collect system information". 

Link to comment
Share on other sites

  • 0

I'm experiencing a similar issue. CloudDrive asks me to reanalyze every time I reboot. Even more recently it hasn't been able to connect at all. I fear that my data has been lost. Is the product still supported? My last question went a couple days without a response.

 

Specifically this screen: http://imgur.com/PvyDEav

 

I have two drives. One 10 TB and one 50 GB on the same account. I just got the first drive to work but I tried a bunch of different things. I ended up deleting all StabeBit Google access from https://myaccount.google.com/u/5/permissions(I had close to 8 or 9 from trying to reauthorize) and that's when the first drive worked.

 

EDIT: 10 minutes later after I took the screenshot the 10 TB finally loaded. That is a scary, scary seemingly fickle process. Is there something I can do to make sure things are working okay?

Link to comment
Share on other sites

  • 0

@ccoleman I get that often. For whatever reason, my 16TB drive does this frequently and it takes almost 2 hours to finish. Thankfully, everytime it does happen, it comes back. Sick of these mini-heart-attacks, though.

 

@Christopher Sad to report that with 10 different GDrive encrypted containers mounted - restarting my server takes forever, and almost always results in the same situation as @JohnKimble. Perhaps CloudDrive can't gracefully unmount 10 before Windows forces and completes a restart. Quite unnerving.

Link to comment
Share on other sites

  • 0

I am having this issue to.. It's only when I have data upload pending. Size of the clouddrive matters I'm currently set at 256TB even though it's not using it all it has to verify and takes 6 hours now. Used to only take 4 hours with the 16TB drives. 

Link to comment
Share on other sites

  • 0

@ccoleman I get that often. For whatever reason, my 16TB drive does this frequently and it takes almost 2 hours to finish. Thankfully, everytime it does happen, it comes back. Sick of these mini-heart-attacks, though.

 

@Christopher Sad to report that with 10 different GDrive encrypted containers mounted - restarting my server takes forever, and almost always results in the same situation as @JohnKimble. Perhaps CloudDrive can't gracefully unmount 10 before Windows forces and completes a restart. Quite unnerving.

 

It shouldn't matter.  The "StableBit CloudDrive Native Service" explicitly halts the shutdown process to ensure that the StableBit CloudDrive Service is able to gracefully shutdown.   In fact, that's it's SOLE PURPOSE. 

 

But clearly something is going wrong here.  And that is something we definitely need to look into. 

 

If you haven't already, open a ticket at https://stablebit.com/Contact

 

Once you've done that, do this:

http://wiki.covecube.com/StableBit_CloudDrive_Boot_Time_Drive_Tracing

And then run the StableBit Troubleshooter:

http://dl.covecube.com/Troubleshooter/StableBit.Troubleshooter.exe

 

 

I am having this issue to.. It's only when I have data upload pending. Size of the clouddrive matters I'm currently set at 256TB even though it's not using it all it has to verify and takes 6 hours now. Used to only take 4 hours with the 16TB drives. 

 

The verify time is dependant on the local cache size, and your upload speed. The smaller the cache is, and the faster your upload is, the quicker this will complete. 

 

But if you could grab the logs (as per above), if you haven't already... that would be helpful.

 

The indexing process runs after every restart for me. I go through the process of un-mounting the drives before a restart and I still have this issue.  It takes a little over a day before all of my drives finish the indexing and are usable again.  I am currently on .827.

 

That's ..... very odd. 

Also, the 827 build is ... rather old at this point.

 

Also, as above. 

 

Sorry for the delay been busy, I tried restarting a few times and I couldn't reproduce the issue anymore.

 

well... I'm glad to hear that this seems to have sorted itself out for you. 

 

But hopefully, we're able to identify and fix this issue for everyone.

Link to comment
Share on other sites

  • 0

EVEN if you detach before reboot it still goes through 8+ hour indexing

That's ... definitely not normal.   

 

When detaching the drive, it saves the database and actually uploads it to t he cloud provider.  When attaching it, it downloads said file and uses that for processing.   So it should NOT be re-indexing. 

 

 

Were you able to get the logs/run the troubleshooter? 

Link to comment
Share on other sites

  • 0

Is the team working on this? I'm getting the same issue, which is pretty annoying. 

 

The software re-indexes the drive everytime I boot up. Had waited till it was fully indexed and rebooted - but it re-indexes all over. Tried re-mounting the drive but no avail.

 

I've uploaded my troubleshooter logs though.

 

EDIT: I decided to re-create a new drive (given the comments on pre-release drives in the other thread), and the issue's resolved. So the issue might be related to drives created with pre-release versions.

Link to comment
Share on other sites

  • 0

I have the same issue and resort to detaching the drive prior to reboot. Is their a way to manually signal the shutdown process in clouddrive so we don't have to reattach the drive on reboot?

 

My understanding is that CloudDrive is SUPPOSED to do this already. The shutdown service that it runs exists specifically for this purpose. We just need to get some attention to the issue and see if Alex can come up with a fix. 

Link to comment
Share on other sites

  • 0

Is the team working on this? I'm getting the same issue, which is pretty annoying. 

 

The software re-indexes the drive everytime I boot up. Had waited till it was fully indexed and rebooted - but it re-indexes all over. Tried re-mounting the drive but no avail.

 

I've uploaded my troubleshooter logs though.

 

EDIT: I decided to re-create a new drive (given the comments on pre-release drives in the other thread), and the issue's resolved. So the issue might be related to drives created with pre-release versions.

 

It's in the queue.  And as for "team", it's just Alex and myself.  I do the customer service and tech support, while he handles the more in depth tech support stuff, and development and everything else.  

 

That said, Alex is aware of the issue (i've brought it up to him directly), so he is aware of it (and I'm sure thinking it over). 

 

As for the release vs pre-release, that's entirely possible.  Depending on the provider, there may have been a lot of changes between when the drive was created and the RC and release versions. 

 

I have the same issue and resort to detaching the drive prior to reboot. Is their a way to manually signal the shutdown process in clouddrive so we don't have to reattach the drive on reboot?

 

This should be happening automatically.  System shutdown should send the "shutdown" command to the service, and start the process.

 

The "StableBit CloudDrive Native Service" is EXPLICITLY there to halt the shutdown process so that the system does not just terminate the main service.   And it is handled this way, well.... to prevent the exact issues you're seeing.   

 

So something is definitely going on here. 

 

Though, it may worth seeing if this happens only on pre-release drives or on newer drives, as well.

 

 

That said, you can manually stop the service by opening up the Services management console (run "services.msc", or open Computer Management).  

Link to comment
Share on other sites

  • 0

It's in the queue.  And as for "team", it's just Alex and myself.  I do the customer service and tech support, while he handles the more in depth tech support stuff, and development and everything else.  

 

That said, Alex is aware of the issue (i've brought it up to him directly), so he is aware of it (and I'm sure thinking it over). 

 

As for the release vs pre-release, that's entirely possible.  Depending on the provider, there may have been a lot of changes between when the drive was created and the RC and release versions. 

 

BTW, apologies if my earlier post sounded harsh - that was definitely not my intent, and I know it's a small team of 2 managing everything.

 

If I can recollect on my problems - it was all fine and dandy when I upgraded to the release version (0.870). The issue started to kick in between Builds 870-880. I'm not entirely sure if the break was server led (I'm using Google Drive BTW). 

 

But I can confirm that the issue is solved when I re-created the drive w/ the release version. My old drive was created way back in the early beta builds.

 

And kudos to a great product: I've been an early beta user and it's amazing to see how polished this product has become. Looking forward to the product's deeper integration with Drivepool.

Link to comment
Share on other sites

  • 0

The "StableBit CloudDrive Native Service" is EXPLICITLY there to halt the shutdown process so that the system does not just terminate the main service.   And it is handled this way, well.... to prevent the exact issues you're seeing.   

 

So something is definitely going on here. 

 

Though, it may worth seeing if this happens only on pre-release drives or on newer drives, as well.

 

 

That said, you can manually stop the service by opening up the Services management console (run "services.msc", or open Computer Management).  

 

Thanks Christopher! Just to clarify, I see the Native service is listed as "Stablebit CloudDrive Shutdown Service", this is in addition to the primary Stablebit CloudDrive Service. I'm assuming I should stop down the primary "Stablebit Clouddrive Service." If so, I can just create a batch file with elevated privileges to to stop the service then restart the machine whenever I need to restart. Thanks again!

Link to comment
Share on other sites

  • 0

Thanks Christopher! Just to clarify, I see the Native service is listed as "Stablebit CloudDrive Shutdown Service", this is in addition to the primary Stablebit CloudDrive Service. I'm assuming I should stop down the primary "Stablebit Clouddrive Service." If so, I can just create a batch file with elevated privileges to to stop the service then restart the machine whenever I need to restart. Thanks again!

 

Yes, you would want to stop the "StableBit CloudDrive Service", as this the 'heart and soul' of the software. 

 

The "Native" service exists .... see below. 

 

 

Will Windows eventually force kill services if they take too long to close gracefully? If so, does the Shutdown Service explicitly avoid this happening?

 

No.  Specifically, the "StableBit CloudDrive Native Service" exists solely to prevent this.  In fact, you may see the normal "waiting on" and this service mentioned when shutting down.

 

This service delays the shutdown until the main service has a chance to gracefully shutdown.  (at least, that's what is supposed to happen).  

 

So, this prevents Windows from forcibly unloading the service.  

BTW, apologies if my earlier post sounded harsh - that was definitely not my intent, and I know it's a small team of 2 managing everything.

 

If I can recollect on my problems - it was all fine and dandy when I upgraded to the release version (0.870). The issue started to kick in between Builds 870-880. I'm not entirely sure if the break was server led (I'm using Google Drive BTW). 

 

But I can confirm that the issue is solved when I re-created the drive w/ the release version. My old drive was created way back in the early beta builds.

 

And kudos to a great product: I've been an early beta user and it's amazing to see how polished this product has become. Looking forward to the product's deeper integration with Drivepool.

 

No, you didn't. So no worries.   I just wanted to clarify!  (to be honest, even if it does come off as harsh, I try to always assume the best, and chalk it up to a "bad day". 

 

 

 

As for the version differences, that is definitely "odd".  The changes are documented, and the only major changes are the read only and "mount disconnected" features.    Nothing here should really cause this sort of issue to have cropped up.

 

 

 

That said, I'll let Alex (the developer) know, just in case it's helpful. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...