agend07 Posted April 2, 2016 Report Share Posted April 2, 2016 hello - I have docker image (https://hub.docker.com/r/agend07/btsync/) which is based on pretty popular (https://hub.docker.com/r/ctlc/btsync/). since 1st April containers based on this image spits a lot of errors like this: 'assert failed /mnt/jenkins/workspace/Build-Sync-x64/network.cpp:3266' otherwise everything is working fine. You have any idea what is going on and what is the fix? The docker container was based on debian:wheezy, I've updated it to ubuntu:14.04 but it didn't help. Containers are working on CoreOs Quote Link to comment Share on other sites More sharing options...
denormal Posted April 3, 2016 Report Share Posted April 3, 2016 Possibly related, I am also seeing network-related "assert failed" in the logs running on Debian v8.4 (jessie) on amd64: assert failed /home/jenkins/slave-root/jenkins-Build-Sync-Manually-309/network.cpp:2738 The difference in line numbers may be related to the different build architectures - the assertion may be being triggered by the same conditions as experienced in the original report. Here are the details on the installed package: % apt-cache show btsync Package: btsync Version: 2.3.6-1 Architecture: amd64 Maintainer: BitTorrent, Inc. <support@getsync.com> Installed-Size: 9894 Depends: libc6 (>= 2.4) Homepage: https://www.getsync.com Priority: extra Section: net Filename: pool/non-free/b/btsync/btsync_2.3.6-1_amd64.deb Size: 5191642 SHA256: e730aa9f30fccdda2cea7679d3f506042e246d7c9514591a7c799dcf22cac129 SHA1: 6cc9bcd885151596e575f49cbdcb563ab51d4605 MD5sum: 7d553ca1c7a0757a0531a3140f7232ed Description: BitTorrent Sync is a proprietary peer-to-peer file synchronisation tool. It can sync files between devices on a local network, or between remote devices over the Internet via a modified version of the BitTorrent protocol. Description-md5: 76747236cd3fbbff26384c3d342dbba0 I'm noticing btsync dropping client connections after a short period of file transfer, although this may be related to local configuration and not the result of this assertion failure. Quote Link to comment Share on other sites More sharing options...
GreatMarko Posted April 3, 2016 Report Share Posted April 3, 2016 @agend07, @denormal - have a quick search of the forums; other instance of "assert failures" on "network.cpp" have been due to Sync exceeding speed limits - see this post for example. Quote Link to comment Share on other sites More sharing options...
denormal Posted April 3, 2016 Report Share Posted April 3, 2016 @GreatMarko - thanks for your quick reply. After posting this I did see that thread - however I'm not sure if this applies. According to the web UI there are no speed limits imposed (attached), and I can't see an upload or download limit in /etc/btsync/config.json or /etc/btsync/user_config.json: { "listening_port" : 0, "storage_path" : "/var/lib/btsync/", "pid_file" : "/var/run/btsync/btsync.pid", "agree_to_EULA": "yes", "webui" : { "listen" : "xxxx" } } Or am I looking in the wrong place? Are there build-time defaults that are being enforced (unlikely)? The assertion failures have come at times when the web UI is reporting transfers at different rates (handful of KB/s through to MB/s). As reported by @agend07 it doesn't appear to be affecting performance. Quote Link to comment Share on other sites More sharing options...
Helen Posted April 8, 2016 Report Share Posted April 8, 2016 note the network.cpp<xxxx>, they are all different. for each build they will mean something different. @agend07 what exactly version of Sync you use. @denormal are you using official package, also what exactly build is it? Quote Link to comment Share on other sites More sharing options...
denormal Posted April 8, 2016 Report Share Posted April 8, 2016 @Helen, I'm using the official Debian packages provided by BitTorrent (as detailed in the BitTorrent blog), with package information given above. The web UI is reporting version 2.3.6 build 378. Quote Link to comment Share on other sites More sharing options...
Helen Posted April 8, 2016 Report Share Posted April 8, 2016 @denormal in your case it means "invalid socket", attempt to option peer's IP was made on invalid socket. having only one line asked, this is the most I can reply with. For more details we need full debug log. Quote Link to comment Share on other sites More sharing options...
denormal Posted April 8, 2016 Report Share Posted April 8, 2016 @Helen - thanks for looking into this. I didn't have debug logging enabled so can't shed any further light on the issue. This does not appear to be affecting overall performance (at least that I am aware). Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.