Recommended Posts

btsync stopped running on both of my Linux boxes within 20 minutes of starting them and syncing. This has happened a couple of times. Before I manually restart them and restore overwritten files, what diagnostic info do you want, exactly? There's nothing relevant to the btsync process in /var/log/messages. And bin/.sync/sync.log doesn't show anything unseemly. It just ends after a bunch of "incoming connection" entries, which is 6 minutes after the last file's piece was completed.

Share this post

Link to post

Share on other sites

OK, I've started btsync on both Linux boxes with all debug information enabled. When one dies, I'll post here. I guess the best way to provide those large files will be via a sync folder.

I should mention that when I restarted the Linux clients, they began overwriting new with old, as expected. What's more, if I copy the newer versions on top of the older versions, this time one of the Linux clients just keeps re-overwriting them. When I simply delete the clobbered files (planning to add them back later from saved copies), that same Linux box just keeps adding them back.

about 15 minutes later: One of my Windows clients just crashed. In all the time I've been using btsync, I've never seen it crash on a Windows client. I selected the option to send crash info to the developers. After restarting it, it syncs without overwriting any new with old, but also I haven't been changing any synced files because of this problem.

about 30 minutes later: One Linux client's btsync stopped running, but there is no core in the bin directory. I PM'ed you log location info.

Share this post

Link to post

Share on other sites

Eleven hours later, and the fix is still working. But I just want to add that the same files the Linux devices kept adding back are now being added back by my Note 2. It's not overwriting because the originals have moved. So when the Note 2 adds them back, I delete them. On each round, the number of files it adds back become fewer and fewer, and now it's down to one. This is the same behavior I saw on my Linux boxes before the fix. Meanwhile, my S4 hasn't shown any problems.

Share this post

Link to post

Share on other sites

Yes. First of all - try starting btsync with --nodaemon switch and see what will it say to the console. Also,m make sure that your terminal has ulimit -c unlimited and make a core dump of the process when it starts consuming 100% CPU time and not responsive.

- "mutex check failed" indicates that the SyncID file was not found in the directory "/srv/backups/test2" - or BTSync failed to get access there. Please make sure that you did not delete this file and the user running btsync has enough permissions to read and write to the folder.

- "Changing IP address from 192.168.8.250 to 0.0.0.0" indicates that you no longer has network. Obviously, btsync won't be able to sync when net is down.