Synology Crash

[ups90]

My diskstation (ds214+ &212+) both have the problem that the application stops when i go to the gui on port 8888

 

when i restart the application it stays on for 5 minutes and than the same thing happens (it crashes)

 

who has the same problem?

 

i have DSM version 5 on my both station and running Firefox and internet explorer en both havening the same problem

 

Kind gerards

[RomanZ]

ups90,

 

Which version of BTSync do you use? Also, could you please provide a core dumps of the crashed process so we can find out the root cause?

 

Thanks!

[Konstantin]

Also see it crashing on synology DS.

 

Config:

 - DS210j

 - DSM 5.0-4458 Update 1

 - btsync 1.3.67 (installed from http://www.synocommunity.com/)

 

Behavior:

 - Normal startup, btsync goes into loading of shared folders. Maybe important: One of two shared folders contains lots of subfilders and small files (>60k).

 - After a while crashes with "Segmentation fault" or "Invalid instruction" message on console (when started with --nodaemon)

 - During the whole run time until crash it is possible to open WebUI, however it doesn't show any dynamic content: shared folders table is empty; "Add Folder" dialog opens, but also doesn't show any content; "Preferences" dialog doesn't open.

 

Log:

[20140402 21:10:15.780] total physical memory -1 max disk cache 2097152

[20140402 21:10:15.794] Using IP address <...>

[20140402 21:10:15.806] Loading config file version 1.3.67

[20140402 21:10:15.882] Loaded folder <...>

[20140402 21:19:27.761] Loaded folder <...>

[20140402 21:22:38.904] NAT-PMP: Unable to map port with NAT-PMP.

[20140402 21:22:51.926] NAT-PMP: Unable to map port with NAT-PMP.

[20140402 21:23:36.559] Incoming connection from <...>:24521

[20140402 21:23:36.768] Incoming connection from <...>:64992

[20140402 21:23:37.100] Incoming connection from <...>:28796

[20140402 21:23:37.734] Incoming connection from <...>:24521

[20140402 21:23:37.804] Incoming connection from <...>:65003

[20140402 21:23:39.819] NAT-PMP: Unable to map port with NAT-PMP.

[20140402 21:23:52.926] NAT-PMP: Unable to map port with NAT-PMP.

[20140402 21:24:09.239] Incoming connection from <...>:65034

[20140402 21:24:16.958] Incoming connection from <...>:24521

[20140402 21:24:17.249] Incoming connection from <...>:65041

[20140402 21:24:18.527] Incoming connection from <...>:56389

[20140402 21:24:25.098] Incoming connection from <...>:24521

[20140402 21:24:34.886] NAT-PMP: Unable to map port with NAT-PMP.

[20140402 21:24:44.263] Incoming connection from <...>:28796

[20140402 21:24:47.817] NAT-PMP: Unable to map port with NAT-PMP.

[20140402 21:24:49.245] Incoming connection from <...>:65047

[20140402 21:24:56.097] Incoming connection from <...>:24521

[20140402 21:24:56.124] Incoming connection from <...>:65048

Also noticed that option "--log file - force logging to file in non-daemon mode" has no effect.

[GreatMarko]

Konstantin, the latest version of Sync is 1.3.80. There were a number of crash fixes made in both 1.3.77 and 1.3.80. Please update to 1.3.80, and see if that resolves your issue.

[Konstantin]

1.3.80 seem to be better - doesn't crash, synchronization started and ongoing. However WebUI still not working.

[RomanZ]

Konstantin,

 

As I understands, the UI "is not working" in the same way as before: it loads, but shows no dynamic content (folders, upload / download values, etc), correct?

 

 

If yes, I suggest cleaning up the cookies / trying another browser.

If no, could you please elaborate?

[Konstantin]

But it looks like syncing folders with such a big amount of files is quite impractical - btsync takes too many resources. With ~60k files startup is already very slow on NAS, and process consumes a lot of memory and CPU. And I need >300k.

Turned out that it's just ve-e-ery slow on updating the dynamic content - If I leave the page opened for several minutes, the dynamic content finally appears.

 

It's a pity, solution seemed to be so promising at a first glance.

Are there any plans on changing the file change detection algorithm to reasonably support large amount of small files?

[RomanZ]

Konstantin,

 

Unfortunately the "Large amount of files" case is not very well supported by the very OS. If we'll find a good solution for it - we'll implement it.

 

For the WebUI - it is going to be remastered in future to be faster and more convenient.

[Konstantin]

Thanks for your reply, Roman. I know very little about btsync internals, so perhaps there are good reasons for doing it the current way, but just an idea: how does btsync change detection algorithm compares to that of rsync? rsync seem to be fine with any amount of files. I'm now speculating, please correct me if I'm wrong, but I presume that the difference is that btsync registers for the OS notifications for the changes in filesystem, while rsync scans through the filesystem on every sync. If this is the case, maybe it makes sense to introduce a threshold for the amount of files in a subfolder and switch to scanning mode if exceeded? For scanning it should always be possible to throttle it to the reasonable speed to keep CPU/RAM usage within limits. Of course, this would create an additional sync lag, but taking into account that currently it may not work at all with limited resources, that would be a reasonable compromise.

[RomanZ]

Konstantin,

 

BTSync uses both system notification (which become less reliable on large amount of files) together with folder rescan. Thanks for the idea, i'll let development know.

[Konstantin]

Roman,

 

I explored that case with big amount of files in a shared folder a bit further. Here are some more inputs, that may be of interest:

 

Removing all user files from that big shared folder didn't solve the problem immediately - although btsync was showing 0 files in the folder and there were no peers to sync this folder with, btsync still consumed quite some resources (mainly RAM) and WebUI was still very unresponsive.

 

As next, I wanted to completely remove the folder from sharing, via WebUI, and it didn't work - after clicking OK in the delete confirmation popup nothing happened.

 

I looked then at the AJAX communication of the WebUI, and discovered something nasty: JS sends 'getsyncfolders' request every second... no matter what was the result of the previously sent requests! Then the explanation for not working folder remove became evident: As server was responding very slowly, it took minutes until the folders info initially updated and the "remove" button appeared. All subsequent update requests were processed very slowly too. Since I was not staring at the screen all the time to react immediately once remove button appeared, every extra minute of waiting added another 60 'getsyncfolders' requests to the queue less few that were processed. Then, as remove request was finally posted, there were already so many 'getsyncfolders' requests pending upfront, that the processing never reached this remove request, before browser marked it as failed by timeout. I additionally confirmed this the root cause by clicking remove as soon as possible next time and watching the network activity - the folder was successfully removed as the processing reached the remove request. btsync immediately resumed normal operation.

 

Proposed solution: count pending 'getsyncfolders' requests in JS, and skip/delay further requests if the counter is above a certain limit. Actually, for update period of 1s I'd say just one pending request is enough, max. two.

[RomanZ]

Konstantin,

 

Thanks a lot for such impressive issue analysis! Let me check how quickly the issue can be fixed with development.