tuxpoldo

Members
 View Profile  See their activity

  • Posts

    730

  • Joined

  • Last visited

  • Days Won

    27

 Content Type 

Everything posted by tuxpoldo

  1. tuxpoldo
    Thank you for the information! I will add it to the package dependencies. See Issue #39
  2. tuxpoldo
    Thank you vadimt for the answer! This would eventually be a useful technical solution to the problem. However, this draws attention to the issue of the terms of use of the API: All the scripts in the packages btsync and btsync-user are currently open software and after reading the terms of use of the API I have the impression, that it is not possible to use the API from open software (that's the reason both Mark Johnson and me have still not used any API function in our code). Is there any new official statement about this?
  3. tuxpoldo
    This method is OK if you do not want BitTorrent Sync to be autostarted on logon. In any case I have a question regarding the use case: do you want to not start BitTorrent Sync because you do not want it to use network resources, or do you really want to start it only on demand? I ask this question because I'm thinking about making the paused state persistent across sessions. In that case, if you pause btsync from the indicator menu, after restarting your system the btsync engine would not restart but the indicator would still be present. In order to resume syncing, you could resume it from the indicator menu. (See Issue #12)
  4. tuxpoldo
    p.S.: What I wrote previously, is not totally true. In the older versions of BitTorrent Sync, you could create the debug.txt file and BitTorrent Sync immediately detected that there was a change in the logging options. Now the debug.txt file seems to be read only on startup. In my previous example I created the debug.txt file after starting BitTorrent Sync (that previously caused BitTorrent Sync to immediately increase the logging level). If you create it before, you will get a lot of output. The only problem, is that this breaks the feature of enabling and disabling debug logging in btsyncindicator included in btsync-user. In conclusion I must realise that there were some serious but undocumented changes in the way BitTorrent Sync handles logging (and perhaps some more things). In order to maintain well functioning packages for linux users, I need to know, how to proceed. If you are not willing to restore the previous behaviour of logging or to make it configurable, I have to redesign fundamental parts of the init script in the btsync package and the runtime script in the btsync-user package. My only concern is: will you change this again in future?
  5. tuxpoldo
    BTW: I tested starting BitTorrent Sync manually in order to verify, that all logging information is written to stdout when --nodaemon is specified. In order to get a lot of logging information, I have also created the debug.txt file containing FFFF in the storage_path The result shows that it is not really true, that all logging information is written to stdout. See yourself: yeasoft-gate2 /etc/init.d # /usr/lib/btsync/btsync-daemon --nodaemon --config /etc/btsync/debconf-default.conftotal physical memory 536870912 max disk cache 2097152Using IP address xx.xxx.xxx.xxxLoading config file version 1.2.71Loaded folder /mnt/data/btsync-areas/leoLoaded folder /mnt/data/btsync-areas/andreaLoaded folder /mnt/data/btsync-areas/leo-andreaLoaded folder /mnt/data/btsync-areas/adm-yeasoftLoaded folder /mnt/data/btsync-areas/leo-marisaThis output is far away from the output you normally have in the log file....
  6. tuxpoldo
    Serious change in BitTorrent Sync's logging Starting from version 1.2, BitTorrent Sync does not produce any log file output when installed with the server (btsync) and the desktop (btsync-user) packages for Debian or Ubuntu. The developers have confirmed that there was a change in the way BitTorrent Sync handles log output. More information can be found here. We are currently discussing about possible solutions, so stay tuned.
  7. tuxpoldo
    Serious change in BitTorrent Sync's logging Starting from version 1.2, BitTorrent Sync does not produce any log file output when installed with the server (btsync) and the desktop (btsync-user) packages for Debian or Ubuntu. The developers have confirmed that there was a change in the way BitTorrent Sync handles log output. More information can be found here. We are currently discussing about possible solutions, so stay tuned.
  8. tuxpoldo
    Thank you for the clarification. Unfortunately this is a serious issue for both packages btsync and btsync-user, since in this deployment scheme BitTorrent Sync will be started using the standard linux facility start-stop-daemon that handles all the process control and PID stuff. This substantial change in the way logging is handled, makes things much more complicated, since the whole handling in both packages has to be redesigned. In my opinion, the best solution would be to have an option in the configuration file that permits to define a logging target (stdout, file and syslog). What do you think about this?
  9. tuxpoldo
    Is this the result of updating a machine that was working fine previously, or are you using a brand new installation?
  10. tuxpoldo
    Thanks! A few days ago, schlegel11 also reported the same problem, but he did not include so much useful information as you did. I tried to reproduce the problem on my Raspberry PI running under Raspian, but I was not able to do so. The Information that you are using RaspBMC may be very useful in order to debug the problem. I will try to create a similar setup on my Raspberry PI in order to reproduce the situation. This morning I got a possible workaround from schlegel11: He wrote that the following solution solved his problem. Maybe you can test it in the meantime.... (Obviously this command has to be executed as root) sudo ln -s /lib/arm-linux-gnueabihf/ld-linux.so.3 /lib/ld-linux.so.3
  11. tuxpoldo
    I see that a lot of people here is posting log files. Under Linux the log file feature seems to be broken since 1.2.67 See this thread for details. Update: Fixed with 1.2.73
  12. tuxpoldo
    After updating a machine where btsync was installed since 1.0.116, I verified, that the log file has stopped working on November 5. This was the date, when btsync was updated from 1.1.82 to 1.2.67. yeasoft-gate2 ~ # ls -la /var/lib/btsynctotal 10476drwx------ 2 root root 4096 Nov 12 13:40 .drwxr-xr-x 45 root root 4096 Nov 3 13:15 ..[omitted]-rw------- 1 root root 5096 Nov 12 13:40 settings.dat-rw------- 1 root root 5124 Nov 12 13:40 settings.dat.old-rw------- 1 root root 3075 Nov 12 13:40 sync.dat-rw------- 1 root root 3075 Nov 12 13:30 sync.dat.old-rw------- 1 root root 85324 Nov 12 13:40 sync.lng-rw------- 1 root root 25958 Nov 5 16:43 sync.log-rw------- 1 root root 6 Nov 12 13:40 sync.pid-rw------- 1 root root 206647 Nov 12 13:40 webui.zip
  13. tuxpoldo
    The problem persists also in 1.2.71 - no log file is generated in the storage_path
  14. tuxpoldo
    Unfortunately the changelog says nothing about it. I would like to wait a few hours before releasing btsync-common 1.2.71-1 since I want to see, if my change in 1.2.68-2 fixes the problem when updating. In order to achieve this, 1.2.68-2 should reach a certain level of distribution....
  15. tuxpoldo
    When they say "in the .sync folder" they mean "in the storage_path" folder. The .sync folder is only the default, if you have no configuration file. p.S.: See this new topic.
  16. tuxpoldo
    During this discussion with knireis I discovered, that btsync 1.2.68 has stopped saving it's log file in the storage_path. Also creating the ominous debug.txt file in the storage_path has no effect. It seems that the entire logging in 1.2 is broken, since I found absolutely nothing. Look: linux-dev-64 /var/lib/btsync # echo FFFF > debug.txtlinux-dev-64 /var/lib/btsync # service btsync restart* Stopping P2P file synchronisation daemon(s)...* Stopping btsync instance 'debconf-default' ...done.* Starting P2P file synchronisation daemon(s)...* Autostarting btsync instance 'debconf-default' ...done.linux-dev-64 /var/lib/btsync # ls -latotal 316drwxr-xr-x 2 root root 4096 Nov 12 12:07 .drwxr-xr-x 42 root root 4096 Nov 6 21:05 ..-rw-r--r-- 1 root root 5 Nov 12 12:07 debug.txt-rw-r--r-- 1 root root 2714 Nov 12 12:07 settings.dat-rw-r--r-- 1 root root 2714 Nov 12 12:07 settings.dat.old-rw-r--r-- 1 root root 210 Nov 6 21:15 sync.dat-rw-r--r-- 1 root root 85324 Nov 12 12:07 sync.lng-rw-r--r-- 1 root root 6 Nov 12 12:07 sync.pid-rw-r--r-- 1 root root 206647 Nov 12 12:07 webui.ziplinux-dev-64 /var/lib/btsync # cat /etc/btsync/debconf-default.conf//!/usr/lib/btsync/btsync-daemon --config//// Default instance automatically created by debconf//// DO NOT EDIT THIS FILE MANUALLY - SERIOUSLY//// THIS FILE WILL BE OVERWRITTEN AT EVERY UPDATE// OR RECONFIGURATION SO DO NOT EVEN TRY IT//// USE dpkg-reconfigure btsync INSTEAD TO MODIFY// THE CONFIGURATION////{ "device_name": "linux-dev-64 - Default Instance", "storage_path" : "/var/lib/btsync", "listening_port" : 0, "check_for_updates" : false, "use_upnp" : false, "download_limit" : 0, "upload_limit" : 0, "disk_low_priority" : true, "lan_encrypt_data" : true, "lan_use_tcp" : false, "rate_limit_local_peers" : false, "folder_rescan_interval" : 600, "webui" : { "listen" : "0.0.0.0:8888", "login" : "admin", "password" : "asd" }}linux-dev-64 /var/lib/btsync # Where has the log file gone?
  17. tuxpoldo
    OK. Fascinating. I tested it now, and I verified that 1.2.68 does not create any log file in the storage path. That means, that if there is a log file from a previous version, nothing is written there any more... I have no idea, where the log file/output is now saved.
  18. tuxpoldo
    Sorry - I forgot to answer: it is totally straightforward. The debug mode of btsync can be enabled as described in the posting from the btsync guys: simply create a text file named debug.txt in the storage_path of the btsync instance you want to enable debug mode. The default instance (the one maintained by debconf) defines its storage_path as /var/lib/btsync The following command executed from a root shell should enable debug mode for the default instance: echo FFFF > /var/lib/btsync/debug.txt
  19. tuxpoldo
    This is a really interesting information. I will try to explain, what am I doing, so this may be of use in order to debug the problem: Initially, everything was contained in one package (btsync). The package manager normally stops the service before replacing the executables. When the package was separated in a common part (btsync-common) that contains only the official components from BitTorrent and the application package (either btsync and/or btsync-user) we had the problem, that the executable was replaced while running and after that, the service was restarted (in the "configure" phase of the package). This is normally not a problem in Linux, since internally the file system keeps the old copy (without and link in the directory) until all file descriptors are closed. I suppose that this seems to work quite differently in an OpenVZ environment. The 1.2.68-2 update was not intended to update the btsync executable itself, but more to prepare the package scripts for the next update (when updating also scripts from the previous package are called). I hope that these changes, will solve the problem when the next update occur. Now the following happens during update of btsync-common: All found services (btsync and/or btsync-user) are stopped (this is done by the old package) The new version will be installed All found services (btsync and/or btsync-user) are started (this is done by the new package)I hope that this will solve the problem with the update. Please let me know, what happens during the next update of btsync-common. Thank you for your patience!
  20. tuxpoldo
    Yes. I do not now how you managed it, but you have added the Ubuntu PPA to your package sources. I have no idea why you did that. Ubuntu does not provide packages for debian. Please remove the Ubuntu PPA from your sources and follow the instructions in the initial posting to add a correct source for your distribution. p.S.: Interesting: the readynas package source offers a package named btsync... This should not interfere, since the packages from my source are newer.
  21. tuxpoldo
    This is correct. It is a consequence of the separation of the core from the application packages. I'm working on a solution...
  22. tuxpoldo
    Is anybody out here able to reproduce this and collect some additional information? All my machines (i386, amd64 (Ubuntu 12.04 LTS) and armhf (Raspbian)) did the update and automatically restarted the daemon during the update... After the update the web interface was reachable and displayed 1.2.68 One question to knireis: What do you mean, when you say "restart the server"? Does this mean, that after the update the web interface was not reachable and you had to reboot your server or you had to restart btsync because the web interface was not reachable any more?
  23. tuxpoldo
    No - the difference was only in the install script (automatic restart of the daemon), and now your installation is done.
  24. tuxpoldo
    The new version 1.2.67 has been released and I'm planning to add debconf support for all the new advanced configuration parameters. I already added the new strings to the translation project. It would be really nice, if you find some minutes to visit the PO Editor btsync-deb project and add the missing strings of your favourite language. Many thanks for your help!
  25. tuxpoldo
    Probably you were the first one to upgrade - Unfortunately I uploaded to my repositories an older version that did not restart the daemon if found. After updating, I found out that someone did a download. Probably it was you ;-) 2001:4dd0:fbc4:0:10ff:44b6:5044:528d - - [05/Nov/2013:16:42:13 +0100] "GET /btsync/pool/main/b/btsync-common/btsync-common_1.2.67-1_amd64.deb HTTP/1.1" 200 3445808 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.15)"xxx.x47.134.19 - - [05/Nov/2013:16:46:44 +0100] "GET /btsync/pool/main/b/btsync-common/btsync-common_1.2.67-1_amd64.deb HTTP/1.1" 200 3445752 "-" "Debian APT-HTTP/1.3 (0.9.12.1)" (The first download was one of my test machines)