[SyncDb: failed to execute query to save file info]

ok - indexing is running (fast) right now - we will see if this solves the problem.

@dantounet: how many files do you manage through sync? Maybe we (or I) reached some limit somewhere?

Cheers,

C.

[Torrent magnet (…) status:137 error:<NULL>]

Hello,

I'm doing some load-test with Sync:

~340G, dispatched in 149k+ files, with recursions (more than 10 subdirectories)

I'm wanting to sync those data from one host (call it "master") to two others (call them "slaves").

At the begining, Sync seemed to work as expected, syncing data and so. Then, after about 6G of transmitted data, nothing seems to move.

I enabled the debug, and found out many errors, like:

Torrent magnet (…HASH…) status:137 error:<NULL> meta:0 conns:1 io:0

What does it mean?

Thank you!

Cheers,

C.

[SyncDb: failed to execute query to save file info]

Hello,

Same problem in here - and it seems to prevent Sync to work normaly - I have about 340G to sync (from a "master" host to 2 "slaves", and it did only 6.8 on one, 6.2 on the second…

These 340G represent about 149541 files (yes, that much… And this is only a part of the directory I want to keep sync-ed between 20 hosts once it's in production).

I don't know if both problems are related.

Cheers,

C.

[Shell script I wrote to update btsync on linux/unix]

By the way, it's maybe even better to download from the generic link:

http://btsync.s3-website-us-east-1.amazonaws.com/btsync_x64.tar.gz

This way, you just have to provide the architecture, and Voilà. Some md5sum check would be of some use in order to not stop btsync for nothing.

This would mean:

- uncompress in some temporary directory

- md5sum of the newly downloaded btsync binary, compare it with the current one

- IF md5sum aren't the same, do the update

- ELSE discard the update, and try it again the next day.

That said… the best way would be to have distro packages (.deb, .rpm, .ebuild and so on) in order to get a fully system integrated update.

Cheers,

C.

[Shell script I wrote to update btsync on linux/unix]

Hello,

Instead of the killall, it may be better to use some init-script. I did this one on my Debian computers/servers:

#!/bin/sh
# Largely adapted from xdm's init script:
# Copyright 1998-2002, 2004, 2005 Branden Robinson <branden@debian.org>.
# Copyright 2006 Eugene Konev <ejka@imfi.kspu.ru>
### BEGIN INIT INFO
# Provides:		 btsync
# Required-Start: $local_fs $remote_fs
# Required-Stop:	 $local_fs $remote_fs
# Should-Start:	
# Should-Stop:	
# Default-Start:	 2 3 4 5
# Default-Stop:	 0 1 6
# Short-Description: Start/stop the SLiM daemon.
### END INIT INFO
DAEMON=/usr/local/bin/btsync
CONFIG=/etc/default/btsync
DAEMON_OPTS="--config ${CONFIG}"
STARTAS=<username>
case $1 in
start)
su -c "${DAEMON} ${DAEMON_OPTS}" $STARTAS
;;
stop)
kill $(cat /tmp/btsync.pid)
;;
*)
echo 'Usage: start|stop'
;;
esac
# End of file

Smarter, and this allows Sync to start on boot .

The equivalent for Gentoo computer:

#!/sbin/runscript

depend() {
use net
}

start() {
ebegin "Starting btsync"
su -c "/usr/local/bin/btsync --config /etc/btsync.json" <username>
eend $?
}

stop() {
ebegin "Stopping btsync"
kill $(cat /tmp/btsync.pid)
eend $?
}

With the location, you may as well use this command line for tar:

tar zxp <archive> -C /usr/local/bin/

As for the URL, it may be better to fix it in the script, and just pass arch and version as arguments.

Modified script would look like:

#/bin/sh
if [ $# -ne 2 ]; then
echo 'Please provide architecture and version'
exit 1
fi
arch=$1
version=$2
url="http://syncapp.bittorrent.com/1.1.33/btsync_${arch}-${version}.tar.gz"
wget $url -O /tmp/download.tar.gz
tar -xzvf /tmp/download.tar.gz -C /usr/local/bin/ || (echo 'ERROR: unable to download' && exit 2)
service btsync stop
rm -f /tmp/download.tar.gz
service btsync start

Cheers,

C.

[Feedback: BTSync on Linux]

Do you have another btsync process running on the same box? I noticed when I tried to run btsync a second time without the configuration file, it started but ran at 100 cpu. I suspect there is an issue when it tries to grab the same 8888 port that's already in use by the first process.

Hello,

My guess: you may have multiple instances, as long as they

- don't have the same PID file

- don't use the same port

- don't use the same data directory (default ~/.sync)

- don't sync the same directories

This kind of setup may be good for a multi-user use - else, a single instance with multiple directories is far better.