RomanZ

Desktop Latest Build 1.3.80

Recommended Posts

Same problem on raspberry damn previous version seems don't have this bug, now all synching stopped this is my "main" server :(

Web interface say that:

"Don't have permissions to write to the selected folder."

CPU 98%

Too bad.....

I fixed the permissions with a simple sudo chmod.

Same high CPU so went back to Version 1.3.67 and all OK.

Thanks

Rich

Sent from my Nexus 4 using Tapatalk

Share this post


Link to post
Share on other sites

The issue of "Too many open files"  and "Don't have permissions to write to the selected folder." is very severe on 1.3.80 when using BTSync on Docker. (Where ulimit constraints is magnitude more tighter.)

 

I've never had a problem with a previous release so it looks like issue specific on 1.3.80...

 

Edit: I've rolled it back to 1.3.77, and it's definitely working way better than 1.3.80...

Share this post


Link to post
Share on other sites

I'm now seeing heavy CPU usage on my Linux NAS's. They were at a constant 50-70%, so I restarted btsync on both. One now hovers at 18-23%, but the other continues at 70-80%, and it's the backup NAS with less load on it. I haven't been tracking the CPU usage, so I'm not sure when the problem returned. But as I reported in this thread:

 

http://forum.bittorrent.com/topic/21884-is-20-45-linux-nas-cpu-usage-too-high/

 

1.1.70 had pretty much solved the problem by providing 11-13% CPU usage, and that's why I haven't been paying attention to it for seven months. But it's got my attention now.

 

EDIT: I just tried reverting one of the servers to 1.3.77, and it ovterwrote about 100 newer files with their older versions. Is there a clean way to shut down the Linux process and downgrade? The 1.3.77 version is still running between 20-50%, and I'm dreading re-upgrading it.

 

EDIT (later): at this point, 1.3.77 is down under 10% CPU.

Share this post


Link to post
Share on other sites

all,

 

We are aware of the "Too many open files" issue and working on resolution. Will update as soon as we have results.

 

UPD.

all,

 

We've managed to find the root cause. The issue is Linux-specific, we'll prepare the fixed build soon. For now you can roll back to 1.3.77 as temp workaround.

 

Sorry for inconvenience.

Share this post


Link to post
Share on other sites

I just rolled back my other Linux NAS to 1.3.77 the same way as I did the previous one, and it synced without any new files getting overwritten. I wonder why sometimes restarting on Linux is OK, and other times not. Meanwhile, this one is showing 20-30% CPU so far, but the other one stays right around 10%.

Share this post


Link to post
Share on other sites

@firefishy: thanks for the ulimit suggestion. Unfortunately I couldn't (easily) get it to work on Debian 7.

 

@RomanZ: great you're already working on a fix! However, I really want to be able to trust my precious files to btsync. If other users mention files disappearing or getting overwritten by older revisions, combined with my own experience with the open files issue, I'm getting worried. Can you tell us anything to give us some peace of mind? For example, do the developers have a good regression testing suite? :)

 

ps. I should add that I'm very happy you do support Linux.

Share this post


Link to post
Share on other sites

Dpx,

 

Our QA is a group of professionals doing a bunch of manual, automated, regression and other tests on BTSync builds before providing them to a public. Also, we are constantly improving our test coverage to ensure the quality of builds. Some bugs that manage to slip QA testing might be painful for our users, but are good fuel to improve our tests and avoid such situations in future.

 

Please also remember, that BTSync is beta software and we are working hard to improve its reliability.

Share this post


Link to post
Share on other sites

Hi

 

Has some pointed out the high cpu bug came back again to 1.3.8, since I'm using a RaspberryPi I notice this alot.

 

In my Pi bitsync stops responding and says with high cpu usage for long periods of time.

One thing I noticed is if I change the nice value of the main process to say 10, it unblocks and starts to respond to requests.

 

Other thing, bitsync gets confused when 2 sync folders have similar names.

 

Heres my setup.

 

One raspberrypi and one windows 8x64 laptop. The 2 have version 1.3.80 installed.

 

On the raspberrypi I have 2 sync folders with 2 different keys

r1 : /mnt/bitsync/HOX/DCIM

r2 : /mnt/bitsync/HOX2/DCIM

 

On Windows8

w1 : D:\Pictures\HOX

w2 : D:\Pictures\HOX2

 

So her is what happened, bitsync tried to copy the .thumbnails folder I have in r2 to w1!!

Now in w1 I have empy .!sync files with the same structure as on w2.

I notice that only folders that have an initial dot got confused an bit sync tried to cross copie.

 

Here's some logs

[2014-04-07 18:28:42] Blocked downloading file .thumbnails\.thumbdata3-1763508120 due Connection closed
[2014-04-07 18:29:38] Blocked downloading file .thumbnails\.thumbdata3--1967290299 due Connection closed
[2014-04-07 18:29:48] Blocked downloading file .thumbnails\.thumbdata3-1763508120 due Connection closed
[2014-04-07 18:30:42] Blocked downloading file .thumbnails\.thumbdata3--1967290299 due Connection closed
[2014-04-07 18:30:53] Blocked downloading file .thumbnails\.thumbdata3-1763508120 due Connection closed
[2014-04-07 18:31:05] Blocked downloading file .thumbnails\1370649745477.jpg due Connection closed
[2014-04-07 18:31:05] Blocked downloading file .thumbnails\1370649745312.jpg due Connection closed
[2014-04-07 18:31:08] Blocked downloading file .thumbnails\1370649745639.jpg due Connection closed
[2014-04-07 18:31:08] Blocked downloading file .thumbnails\1370649745810.jpg due Connection closed
[2014-04-07 18:31:08] Blocked downloading file .thumbnails\1370649746415.jpg due Connection closed

 

This showld NOT EVER happened, since this 2 folders have 2 separated keys.

Share this post


Link to post
Share on other sites

Ruimg,

 

Couple of things to check.

1. Please check if your HOX2 does not have the files that are in the log. It might happen that your HOX and HOX2 have similar sets of files.

2. How did you create HOX and HOX2 folders? If you create one, then add it to BTSync then copy it - it will bring some service data within, to be precise - .SyncID file which is intended to distinguish one folder from another.

Share this post


Link to post
Share on other sites

Hi RomanZ
 

1. Please check if your HOX2 does not have the files that are in the log. It might happen that your HOX and HOX2 have similar sets of files.

 

Currently I have

HOX on raspberry does not have .thumbnails

HOX2 on raspberry does not have .thumbnails

   "ls -la" was used

 

HOX on win8 has a copy of .thumbnails from HOX2 but inside it has .!sync files with 0 length

HOX2 on win8 has the original .thumbnails folder

 

How did you create HOX and HOX2 folders? If you create one, then add it to BTSync then copy it - it will bring some service data within, to be precise - .SyncID file which is intended to distinguish one folder from another.

 

I forgot to mention HOX and HOX2 are backup folders of the same android phone that I formated. So HOX has the old backup photos and HOX2 has the new backup photos.

So Android => (Raspberry <==> Win8).

 

What I did was on android create a backup folder, share the key by email. On windows I created the HOX2 folder and used the backup key from the email. Then entered webui on raspberrypi and created the folder and pasted the same key,

 

The SyncId Files have different keys.

 

Also notice that HOX2 .thumbnails did not get copied from android to raspberry but got copied from android to win8.

 

I thought It didn't had, but it is possible that the syncid file was present on the android DCIM folder when I decided to create a new backup sync. Still, all worked fine aside the fact that dot folders are being cross copied on windows.

Share this post


Link to post
Share on other sites

What does this error mean:

Closing TCP tracker connection to 54.225.100.8:3000. Error 10060

Also, can you help me with steps to troubleshoot this error:

Failed to open tunnel to ###.###.###.###:#####:TCP"#" is just me masking the numbers.

Share this post


Link to post
Share on other sites

Photoniac,

 

The first error means "Connection time out", i.e. your BTSync did not manage to connect to tracker server over TCP, as tracker did not respond. I'm not sure about the second error, it will take some time to check what does it mean.

 

Second error means that BTSync failed to establish direct connection to another peer. 

 

Could you please share your symptoms? What is not working?

Share this post


Link to post
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.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   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.