[Btsync 1.4.72 Crash On Linux I386]

Same on QNAP TS-290. All company synchronization is now busted. Shame!

[Dot-Directories Not Synced]

Hi Roman, permissions od .htupload are rwxrws--- (2770) and owner is sclare.administrators, btsync runs as admin, i.e. from my point of view btsync is in the administrators group, i.e. should be able to "see" it.

 

For some reason btsync does not see "through" .htupload; when I add explicitly all the respective ..../.htupload/uploaded_files folders, they are added (that is normally not possible for subfolders under a synchronized folder).

 

Jindra

 

P.S. I forgot to mention btsync is version 1.2.91 i386 

[Dot-Directories Not Synced]

Hello,

 

we have to synchronize some files uploaded to an Apache http server. Unfortunately, directory structure looks like /(synchronized_path)/(something)/.htupload/uploaded_files.

 

Everything in /(synchronized_path)/(something) is synchronized, but unfortunately everything down under .htupload is not.

 

It is running on QNAP TS-269Pro (Linux, i386), QTS version 4.0.3.

 

Is there any way to override this default behavior?

 

Thank you,

 

Jindra

[Btsync "accumulating" Cpu Load]

Hello,

 

from what I could observe, once they reach this level (after a day) it stays high and blocks any transfers.

 

 - Since we have it on production machines and do not have better alternative, I put a crontab restart every two hours. After restart, btsync is temporarily busy as it loads all folders anew, but after few minutes, web gui starts working and the load drops to some 18-30%. Peaks occur occasionally, probably during reindexing, but stay temporary.

 

- some 400K+ files, almost 200GB volume, total tree structure has some 18K+ folders. There are about 50 synchronized folders (btsync entries) ranging from few MB up to 34 GB total volume. (We are in a planning phase to put most of it out of sync to a permanent archive, but this is our current load)

 

- CPU on QNAP is dual core Pentium (1.9 GHz IIRC), CentOS machine is a different flavor but also a dual core Pentium.

 

I will have a look for the logs. I will switch off the restarts on weekend and try to collect more information. What we have now would probably not be representative because I installed a regular 2-hour restart in all units.

 

In the meantime we switched off CentOS (it was receiving uploaded files from web server but we redirected the upload directly to the QNAP NAS) so I am afraid it will not provide any more data.

 

Regards,

 

Jindra

[Api Fails After 5 Calls]

Hello,

 

I needed to establish identical structure of synced folders on several NAS units, so I wrote a small app to read list of folders and secrets from a file, call get_folders, then add_folder for each folder from the list not yet in BTSync setup.

 

Interestingly, only 5 api calls complete (1 get_folders and 4x add_folder), then it fails on HTTP 401 - Not Authorized. At this moment the utility exits. After restart, it skips already existing folders and adds 4 more, etc. 

 

It is running on QNAP TS-269Pro (QTS 4.0.5), btsync is 1.2.91 original i386 from BitTorrent download (not the broken binary distributed by QNAP).

 

Utility is written in python, using python 2.7, urllib and urrlib2. Password authentication is handled by creating urllib2.HTTPBasicAuthHandler() and using it in urllib2.build_opener(handler).

 

Does anybody have similar experience of API "getting tired" after few calls shortly following each other?

 

Thanks,

 

Jindra

 

 

 

 

[Btsync "accumulating" Cpu Load]

Hello,

 

we deployed BTSync 1.2.91 (i386 linux version) on 4 linux machines, 1 CentOS and 3 NAS TS-269 (linux-based operating system QTS).

 

I noticed that on various occasions CPU load as dislayed by the top utility shows btsync running at the top with high cpu loads over 85%, often peaking to 99.9%. Some machines reached a consistent 99.9% level after about a day.

 

When the porcessed reached 99.9%, GUI responds slowly, some synced folders appear not to be synchronized (at least in GUI) and there seem to be hanging (infinitely pending) transfers.

 

I noticed similar behavior with version 1.2.82, where CentOS process often crashed with segfault and QTS machines as if "accumulated" load until 99.9% when they stopped working, although the process itself did not crash.

 

Temporary solution implemented is periodical restart of btsync every two hours. After restart, btsync starts at low CPU loads (1 to 10%) and is getting busier as time passes. Before it becomes completely dead it is gracefully restarted by a cron job.

 

Could this be answer to some of you guys who reported insanely slow download speeds?

 

Regards,

 

Jindrich Vavruska

[Linux Segmentation Fault (Kernel I386 2.6.18)]

Hello, have segmentation fault problem similar to what was described elsewhere. Occurs both with btsync_i386-1.2.67 and 1.2.82.

 

Kernel is i386 2.2.18-164.15.1.e15 (CentOS).

 

I originally used GUI to set up directories, but I have to set up about 100 directories and it took extremely long, so I tried these changes:

 

1) disabled GUI, switched to API (already got API key)

2) but before I started using API I discovered that it would be faster to include all directories in the config file, so I included all of them. First few hours it was running, but since certain moment I consistently get segmentation fault in both versions of btsync. This is probably related to reindexing activity, unfortunately I cannot identify which directory is being reindexed when this happens...

 

Jindra