tuxpoldo

No - because the web interface is disabled. But in the log files I can see that the devices are talking each other

I have a question: What is the difference between the i386 and the glibc23_i386 versions (same for amd64 and glibc23_amd64)? Apparently both run on every version of linux I have tested it on, so what's the matter? Here some versions from different machines: Debian 6 (squeeze): tuxpoldo ~ # dpkg -l | grep glib ii libglib2.0-0 2.24.2-1 The GLib library of C routines Debian 7 (wheezy): ape-gate ~ # dpkg -l | grep glib (nothing - no glib installed? Impossible!) Ubuntu 10.04 (lucid) ccm-mgmt ~ # dpkg -l | grep glib ii libglib2.0-0 2.24.1-0ubuntu2 The GLib library of C routines Ubuntu 12.04 (precise) yeasoft-gate2 ~ # dpkg -l | grep -i glib ii libglib2.0-0 2.32.3-0ubuntu1 GLib library of C routines If I look at the internal bindings: yeasoft-gate2 ~/testbtsync # ldd btsync-normal linux-vdso.so.1 => (0x00007ffffcbff000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9a58a4a000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9a58846000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9a58549000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9a5832c000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9a57f6d000) /lib64/ld-linux-x86-64.so.2 (0x00007f9a58c5b000) yeasoft-gate2 ~/testbtsync # ldd btsync-glibc23 linux-vdso.so.1 => (0x00007fff13fff000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fab38fff000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fab38dfb000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fab38afe000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fab388e8000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fab386cb000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fab3830b000) /lib64/ld-linux-x86-64.so.2 (0x00007fab39210000) The only difference is that the glibc23 version loads an additional library (libgcc_s.so.1) and has some different memory mapping.. Which one should be used?

Thank you for the correction! I changed the original posting.

Hi! Thank you for your answer! Will you release in future a documentation covering all configuration directives? Is (or will) there any possibility to disable checking external relay servers? In such a configuration this would not make sense... BTW: In such a setup only with linux boxes, I have the problem that I see no replication working. I have read somewhere that the linux version takes up to 20 minutes to detect file system changes. Is this true? What's about inotify? I found nothing in the logfile reguarding change notifications.

Hi BitTorrent Developers, since I use btsync also for the internal synchronisation of internal files in my servers, I setup some closed configuration, but now I'm wondering, if this is really possible. Look at this configuration file: //!/usr/lib/btsync/btsync-daemon --nodaemon --config // // This btsync instance provides sync services for // all common files in the YeaSoft Server Grid // { "device_name" : "tuxpoldo - Server Sync Instance", "storage_path" : "/var/lib/btsync-serversync", "listening_port" : 11076, "check_for_updates" : false, "use_upnp" : false, "download_limit" : 0, "upload_limit" : 0, "webui" : {}, "shared_folders" : [ { "secret" : "blahblahblah", "dir" : "/mnt/data/tftproot/yeaboot/", "use_relay_server" : false, "use_tracker" : false, "use_dht" : false, "search_lan" : true, "use_sync_trash" : true, "known_hosts" : [ "10.65.4.1:11076", "10.65.0.16:11076", "10.65.18.1:11076" ] } ] } I would expect btsync to do nothing with PNP and not to try to reach any external system. If I look to the log file, I see the following strange things: [20130428 14:15:58] Loading config file version 1.0.134 [20130428 14:15:59] Got 2 relay ips [20130428 14:15:59] Server ip 67.215.229.106:3000 [20130428 14:15:59] Server ip 67.215.231.242:3000 [20130428 14:16:10] NAT-PMP: Unable to map port with NAT-PMP. Question: Why does btsync search for relay servers if I disabled the use of relay servers? Why does btsync try to do any PNP stuff? In my opinion these are serious security flaws that may decrease the trust of users in btsync...

There are Packages available for Debian. Look here. You have two possibilities to administer the installation: you can connect to the headless server via the web ui or you can configure everything in the configuration file.

Version 1.0.134-5 has changes that apply only to the server version. Since both packages are the result of the build process, also the desktop package has a new version, but basically nothing changes except for the version number. Here the changelog: - Fixed: btsync did not start if web gui was configured to operate with no credentials - Fixed: btsync did not stop under certain circumstances if there is more than one btsync.*.pid file in /var/run

Wait a minute! This is probably not sufficient to solve the problem, since there must be reason for this. If the process is running as sierink and was not able to create a file in /home/sierink/.btsync/ there can be only two explanations: Either the user sierink has no suitable rights to the directory /home/sierink/.btsync/ (that would be very strange) or btsync was executed with this configuration file for the first time with other credentials. In that case the directory may have been created by the other users credentials or at least the files in it. Please make sure that both the directory and all the files in it belong to the user sierink. Du this with the following command: sudo chown -R sierink:sierink /home/sierink/.btsync/ BTW - Please update your btsync version. The new packages are online now.

Version 1.0.134-5 is now online for Debian Intel builds. Ubuntu builds are on the way. Debian ARM Builds will follow this evening. - Fixed: btsync did not start if web gui was configured to operate with no credentials - Fixed: btsync did not stop under certain circumstances if there is more than one btsync.*.pid file in /var/run

OK: and now we will see if btsync is running at all: Test if btsync is running: sudo pgrep btsync-daemon If the command prints a number, btsync is running (the number is the pid) If btsync is not running, you must find out why. Probably there is an error in your configuration file. To find out, what is the error, you have to start btsync manually under the credentials of the user under which you want it to run. In this case, make sure you have a shell running under the users credentials and execute the following command: /usr/lib/btsync/btsync-daemon --nodaemon --config /etc/btsync/user.sierink.conf If btsync refuses to run, you will now see some error messages. If instead btsync is running, you can test if it is listening on the internal connection port and for the web ui. Test it by the following command: sudo netstat -tlpen | grep btsync You should get two strings: one showing the listening information for the web ui, the other showing the listening information for the synchronization function.

Sorry, but it seems to me, that you now have a great mess on your system. The output you sent me, seems to have no relationship with all the information you sent me before: it seems that you now have two configuration files in your /etc/btsync directory: the default file created by debconf, and a user specific file created by you named user.conf or similar. Since I have no idea, what are the contents of this new configuration files, I cannot give you any explanation. The worst problem, is that you now have recreated the same situation as before: the bug we have found, manifests itself, when more than one instance of btsync is running and that's exactly what you have done now. One thing is known: if the netstat command did not return anything, no instance of btsync is currently running. This is probably due to conflicts in both configurations you have created. The reason why you do not see any error message, is that the BitTorrent btsync executable unfortunately still does not return any meaningful return code, if it encounters any error situation during startup. Now please do the following: Take a decision if you want a default debconf managed instance, running as root, on your system. If not, please do not install one as you have done now. And please do not remove the configuration by simply deleting debconf-default.conf from /etc/btsync. After any update, it will be automatically recreated because IT IS MANAGED BY DEBCONF (this is also written inside the file). If you do not want such a system managed instance, you have to answer "No" during the initial configuration when being asked if you want a default instance to be created. If you want to change things specified during the installation in the installation dialogs, you must issue the dpkg-reconfigure command. THIS IS A GENERAL RULE OF BEHAVIOUR FOR ANY DEBIAN PACKAGE. In your specific case, you have to issue the command "sudo dpkg-reconfigure btsync" Please let's test your issues with only one configuration file. And please do not change things that stay in no relationship with what we are testing, like the name of the configuration file. And since the bug we found affects the functionality when operating btsync with more than one configuration file, you should now try to have a simple configuration that does exactly what you want.

That's great, since I was not able to create a builder environment for jessie (there is still an error with debootstrap). That should be fine, and if 192.168.1.17 is the TCP/IP Address of your server, it should work without asking you for credentials. In any case you can also specify: "webui" : { "listen" : "0.0.0.0:9999" } In that case, btsync listens on all interfaces of the server in case the server has more than one IP address defined. If you specify an IP address there, it must be one of the addresses of the server. Obviously you must also make sure, that no other process listens on that port. You can verify that btsync listens on port 9999 by entering the following command: sudo netstat -tlpen | grep btsync You should get an output similar to mine: yeasoft-gate2 /etc/btsync # sudo netstat -tlpen | grep btsync tcp 0 0 10.65.0.16:8888 0.0.0.0:* LISTEN 0 950175 30970/btsync-daemon tcp 0 0 0.0.0.0:26185 0.0.0.0:* LISTEN 0 950162 30970/btsync-daemon Here you can see, that my btsync daemon listens on 10.65.0.16 with port number 8888 (as configured in my config file) If you are still not able to connect to the server, perhaps there is a firewall configured, that prevents accepting connections to port 9999 In this case you should configure the firewall accordingly. Another question: Is that machine a server or your workstation? In that case perhaps it would make more sense to install the desktop version of the packages.

OK. I found the bug! Thank you for your valuable help! I will make the fixed version available in the next few hours. I didn't knew that jessie was already available as a defined version name. I will try to setup a build environment in order to produce also packages for jessie. In the meantime: have you tried to use the sid repository instead of the wheezy repository?

One thing more: please send me the result of executing the following commands (sorry - I have no jessie installed): basename /var/run/btsync.debconf-default.pid | cut -c8- BASENAME=$(basename /var/run/btsync.debconf-default.pid | cut -c8-); echo ${BASENAME%%.pid}

Thanks. You can find out if it runs by entering the command: sudo ps ax | grep btsync If the result show up more than the grep command, you entered, than the instance is running: yeasoft-gate2 ~ # ps ax | grep btsync 1963 ? Sl 2:25 /usr/lib/btsync/btsync-daemon --nodaemon --config /etc/btsync/debconf-default.conf 4932 pts/1 S+ 0:00 grep --color=auto btsync Basically there are some problems that I'm trying to understand: There is a PID file in your /var/run directory that should not exist, because according to your config file(s) in the /etc/btsync directory, you have no default config created by debconf. You have a file called /etc/btsync/btsync.sierink.conf and so i would expect only a PID file related to that configuration in the /var/run directory. Its name should be btsync.btsync.pid - so I'm asking myself: where does this file come from? Probably it is a "cadaver" from a previous installation but also in that case it should be possible to delete it... The daemon script /etc/init.d/btsync does the following when stopping: it looks for all files in /var/run according to the pattern 'btsync.*.pid'. After stopping the daemon with the PID supplied by the file, the file will be deleted. Since there is no btsync.btsync.pid file in your /var/run/directory, I suppose that you already have stopped your btsync instance. In your case the script tries also to stop the 'debconf-default' instance. The only strange thing is, that the instance name is not detected correctly: instead of 'debconf-default' the instance name is detected as 'debconf-default.pid'. And for that reason the script tries to delete a pid file, that does not exist: /var/run/btsync.debconf-default.pid.pid Now let's try this fast workaround to help you with your real problem. Please delete the wrong PID-File: sudo rm /var/run/btsync.debconf-default.pid Now try to start the daemon and then stop it: sudo service btsync start sudo service btsync stop Please tell me if this has solved your problem. In the meantime I will try to find out, why the script tries to delete the wrong pid-file under certain circumstances.

One more please: ls -la /var/run/ I suppose, that your instance of btsync was not running when you entered the command?

OK. As I can see, the stop routine is trying to stop two intances (one named 'btsync', the other named 'debconf-default.pid'), but according to your config files, you should only have the instance named 'btsync' running. Can you please show me the contents of your /var/run directory? I need the output of two commands: ls -la /var/run ls -la /var/run/btsync.*.pid We are now very near to find a solution.

That's really interesting. I am trying to reproduce the error, but I am not able to do so. It seems that the decomposition of the name does not work correctly: [....] Stopping btsync instance 'debconf-default.pid' It should say: [....] Stopping btsync instance 'debconf-default' Three questions: 1. Which version of btsync are you using? Find it out by executing: dpkg -l | grep btsync 2. Are you able to stop the service manually? Find it out by executing: sudo service btsync stop 3. What's the name of the configuration file? Find it out by executing: ls -la /etc/btsync On my systems it seem to work: yeasoft-gate2 ~ # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done The following packages have been kept back: linux-headers-server linux-image-server linux-server The following packages will be upgraded: btsync libcups2 libtiff4 python-apt python-apt-common rsyslog 6 upgraded, 0 newly installed, 0 to remove and 3 not upgraded. Need to get 3205 kB of archives. After this operation, 5120 B of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://de.archive.ubuntu.com/ubuntu/ precise-updates/main libcups2 amd64 1.5.3-0ubuntu8 [171 kB] Get:2 http://ppa.launchpad.net/tuxpoldo/btsync/ubuntu/ precise/main btsync amd64 1.0.134-4~precise [2252 kB] Get:3 http://de.archive.ubuntu.com/ubuntu/ precise-updates/main libtiff4 amd64 3.9.5-2ubuntu1.5 [145 kB] Get:4 http://de.archive.ubuntu.com/ubuntu/ precise-updates/main rsyslog amd64 5.8.6-1ubuntu8.2 [427 kB] Get:5 http://de.archive.ubuntu.com/ubuntu/ precise-updates/main python-apt-common all 0.8.3ubuntu7.1 [21.7 kB] Get:6 http://de.archive.ubuntu.com/ubuntu/ precise-updates/main python-apt amd64 0.8.3ubuntu7.1 [188 kB] Fetched 3205 kB in 1s (2307 kB/s) Preconfiguring packages ... (Reading database ... 93152 files and directories currently installed.) Preparing to replace libcups2 1.5.3-0ubuntu6 (using .../libcups2_1.5.3-0ubuntu8_amd64.deb) ... Unpacking replacement libcups2 ... Preparing to replace libtiff4 3.9.5-2ubuntu1.4 (using .../libtiff4_3.9.5-2ubuntu1.5_amd64.deb) ... Unpacking replacement libtiff4 ... Preparing to replace rsyslog 5.8.6-1ubuntu8.1 (using .../rsyslog_5.8.6-1ubuntu8.2_amd64.deb) ... Unpacking replacement rsyslog ... Preparing to replace python-apt-common 0.8.3ubuntu7 (using .../python-apt-common_0.8.3ubuntu7.1_all.deb) ... Unpacking replacement python-apt-common ... Preparing to replace python-apt 0.8.3ubuntu7 (using .../python-apt_0.8.3ubuntu7.1_amd64.deb) ... Unpacking replacement python-apt ... Preparing to replace btsync 1.0.134-3~precise (using .../btsync_1.0.134-4~precise_amd64.deb) ... * Stopping P2P file synchronisation daemon(s)... * Stopping btsync instance 'debconf-default' [ OK ] Unpacking replacement btsync ... Processing triggers for ureadahead ... Processing triggers for man-db ... Setting up libcups2 (1.5.3-0ubuntu8) ... Setting up libtiff4 (3.9.5-2ubuntu1.5) ... Setting up rsyslog (5.8.6-1ubuntu8.2) ... rsyslog stop/waiting rsyslog start/running, process 18216 Setting up python-apt-common (0.8.3ubuntu7.1) ... Setting up python-apt (0.8.3ubuntu7.1) ... Setting up btsync (1.0.134-4~precise) ... * Starting P2P file synchronisation daemon(s)... * Autostarting btsync instance 'debconf-default' Processing triggers for libc-bin ... ldconfig deferred processing now taking place Thank you for your help!

Thanks for the Information. I will fix this as soon as possible. In the meantime, you may work around this problem by creating the file manually and then retrying: sudo touch /var/run/btsync.debconf-default.pid.pid

Version 1.0.134-4 is ready. All Debian builds are now online. Ubuntu builds are on the way and should be online in about 2 hours.

OK! Thanks - found the error - the script of the build machine did not copy one important file. I'm fixing it - In about an hour the new version should be on.

Please check the following: Is btsync running with the generated configuration file? Test it with the command ps ax | grep btsync-agent You should see something like /usr/lib/btsync-user/btsync-agent --config /home/YOURNAME/.btsync.conf Check that all paths specified in the configuration file .btsync.conf in your home directory are correct - especially the storage_path If not 1: do you have logged out and logged in again after updating?

Great work! But please remove the dot after the URL. The correct URL is https://github.com/puppe/btsync-qpkg ;-)

Updated all distributions to 1.0.134-3 - added armel version for squeeze btsync (1.0.134-3~squeeze) squeeze; urgency=low - Fixed: broken parsing of usernames with dashes in btsync configuration files - Fixed: btsync-user does not work correctly due to relative paths in configuration file. Now the configuration file /etc/btsync-user/btsync-user.conf is only a template for generating a user specific configuration file into the home directory -- Leo Moll <leo.moll@yeasoft.com> Mon, 20 May 2013 18:14:11 +0200

Version 1.0.134-3 is ready. All Debian builds are now online. Ubuntu builds are on the way and should be online in about 1-2 hours.