Where does BitTorrent 1.2.xxx store its log files?

[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?

[tuxpoldo]

The problem persists also in 1.2.71 - no log file is generated in the storage_path

[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

[vadimt]

You run btsync with "no-daemon" flag. In this case logs will be written to stdout only in 1.2 version.

Thanks!

[tuxpoldo]

You run btsync with "no-daemon" flag. In this case logs will be written to stdout only in 1.2 version.

Thanks!

 

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?

[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-marisa

This output is far away from the output you normally have in the log file....

[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?

[vadimt]

We will add a function to API for enabling/disabling logs in the next versions or maybe possibility to re-read config after receiving SIGHUP signal. 

Thanks! 

[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?

[sergey@bt]

The reason why we switched to stdout in no-daemon mode is to be compatible with runsv and to allow log rotation. We didn't expect to break anything. Is there any easy way to redirect stdout to file in start-stop-daemon? If not, we will provide an option to force logging into file.

 

Regarding debug.txt - it was changed long ago to check it on start only.

[tuxpoldo]

The reason why we switched to stdout in no-daemon mode is to be compatible with runsv and to allow log rotation. We didn't expect to break anything. Is there any easy way to redirect stdout to file in start-stop-daemon? If not, we will provide an option to force logging into file.

It is a bit complicated. Basically one possibility is to create a wrapper script around the btsync executable. This option creates an interesting possibility of making any way of redirection (either log file and/or syslog). The problem is, that you create an entire tree of processes and on stop/restart I found no way to keep all clean and consistent. Here you can see an example:

The script starts the daemon this way in order to redirect everything to the logger:

 

exec > >(logger -t ${NAME}.${BASENAME})exec 2>&1${BTSYNC} --nodaemon --config ${CONFIG_FILE}

This results in:

 

20467 pts/6    Ss     0:00  \_ /bin/bash 8907 pts/6    S+     0:00  |   \_ /bin/bash ./btsync-daemon debconf-default.conf 8929 pts/6    S+     0:00  |       \_ /bin/bash ./btsync-daemon debconf-default.conf 8931 pts/6    S+     0:00  |       |   \_ logger -t btsync.debconf-default 8930 pts/6    Sl+    0:01  |       \_ /usr/lib/btsync-common/btsync-core --nodaemon --config /etc/btsync/debconf-default.conf

In this case the process started by start-stop-daemon would be 8907. If this process is killed, the following happens:

 

 8929 pts/6    S      0:00 /bin/bash ./btsync-daemon debconf-default.conf 8931 pts/6    S      0:00  \_ logger -t btsync.debconf-default 8930 pts/6    Sl     0:01 /usr/lib/btsync-common/btsync-core --nodaemon --config /etc/btsync/debconf-default.conf

You see that all child processes are still running.

Only if you kill 8930, the whole chain dies. This means: start-stop-daemon creates a process, but on stop it must kill another process. This cannot work. I'm trying to implement a trap handler, but also this is not really working....

 

Regarding debug.txt - it was changed long ago to check it on start only.

OK. I missed this....

[tuxpoldo]

For the server package, I can make a series of changes to the init script in order to work with the pid file maintained by btsync itself. This requires some in depth parsing of the config file, since the location may be specified literally, or computed as "${storage_path}/sync.pid" In this way, I can user start-stop-daemon without the --nodaemon option. Unfortunately this implies also a lot of other changes to the init script, since both the status and the stop command relies on enumerating the pid files (previously created by start-stop-daemon) in /var/run - this has to be changed in order to enumerate the config files stored in the /etc/btsync path....
 
The same problems have to be solved also for the btsync-user package....
 
Sigh...
 
In any case, you would do us all a big favour, if you implement the possibility to specify the logging target on the command line... Let's say:
 
--log stdout
logs to standard output
 
--log file
logs to the standard file ${storage_path}/sync.log
 
--log file://var/log/mylogfile.log
logs to a specific file
 
--log syslog
logs the local syslog with predefined priority and tag
 
--log syslog:server=xyz,port=xyz,priority=xyz,tag=xyz
logs to syslog as specified with the supplied (all optional) parameters

 

 

BTW: The standard package logrotate is able to handle complex methods of letting the application handle the substitution of the logfile...

[vadimt]

Update: We added command line options for force logging on linux  in 1.2.73 version (http://syncapp.bittorrent.com/1.2.73/).

Now it will work like described below:

If you run btsync with --nodaemon, then log will be written to stdout.

If you run btsync with --nodaemon and --log file or without --nodaemon, then log will be written written to the default log file (storage_path/sync.log)

Thanks!

[GreatMarko]

Update: We added command line options for force logging on linux  in 1.2.73 version (http://syncapp.bittorrent.com/1.2.73/).

Now it will work like described below:

If you run btsync with --nodaemon, then log will be written to stdout.

If you run btsync with --nodaemon and --log file or without --nodaemon, then log will be written written to the default log file (storage_path/sync.log)

 

vadimt, it would be worth getting this information added to "Step 1" of the first post of this sticky thread also!

[tuxpoldo]

Thank you very very much for this first step! I know that I'm asking for a lot, but I think that also the more professional users would appreciate syslog support:

 

In any case, you would do us all a big favour, if you implement the possibility to specify the logging target on the command line... Let's say:

--log stdout
logs to standard output

--log file
logs to the standard file ${storage_path}/sync.log ALREADY IMPLEMENTED

--log file://var/log/mylogfile.log
logs to a specific file

--log syslog
logs the local syslog with predefined priority(user.1) and tag(btsync)

--log syslog:server=<server>,port=<portnum>,priority=<prio>,tag=<tag>
logs to syslog as specified with the supplied (all optional) parameters

[Shot2]

BTSync 1.2.73 under vanilla Ubuntu 13.10 x64 Server, still no luck enabling logging.

 

Tried so far:

• adding "--log file" to daemon args in /etc/default/btsync
• adding "--log file" in the /etc/init.d/btsync initscript (ain't that old-fashioned, btw?)
• both solutions above experimented with and without a 'debug.txt' file (containing variously '0' '1' 'ffff' 'omgwtfbbq') in BTSync's storage path.

To no avail.

 

Will gladly send logs if it helps debugging. Oh, wait...

[tuxpoldo]

BTSync 1.2.73 under vanilla Ubuntu 13.10 x64 Server, still no luck enabling logging.

Strange. The latest version of the btsync server packages automatically adds the parameter:

 

yeasoft-gate2 ~ # ps ax | grep btsync-daemon25181 ?        Sl     2:26 /usr/lib/btsync/btsync-daemon --nodaemon --log file --config /etc/btsync/debconf-default.conf25300 ?        Sl     1:11 /usr/lib/btsync/btsync-daemon --nodaemon --log file --config /etc/btsync/serversync.conf

And the logging feature works....

 

yeasoft-gate2 ~ # ls -la /var/lib/btsync/*.log-rw------- 1 root root 544 Nov 17 14:37 /var/lib/btsync/sync.log

Here my versions:

 

yeasoft-gate2 ~ # dpkg -l 'btsync*'Desired=Unknown/Install/Remove/Purge/Hold| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)||/ Name                      Version                   Description+++-=========================-=========================-==================================================================ii  btsync                    1.2.0-1                   Private network P2P file synchronisation daemon(s)ii  btsync-common             1.2.73-2                  Private network P2P file synchronisation daemon

Two words about using old fashioned init scripts: it is true that init scripts are quite old fashioned, but they are still the one and only commonly supported mechanism for maintaining system services across all Debian derived distributions. Ubuntu is using upstart for a while, Debian is moving to systemd like many other distributions, but init scripts are still working everywhere (think about all the Debian derivatives also on embedded platforms...). This is for me a good reason to still work with init scripts... Furthermore there is a lot of brainpower contained in the init script. The support of upstart and/or systemd will still require this brainpower to be contained in collateral scripts. This will not make it even simpler or better....

 

[Dahaniel]

Is there a way to stop logging or move the logfile to /var/log/... when running in daemonmode? I need to redirect the logfiles to a ramdisk as logging is preventing my MyBookLive NAS from spinning down the disk

[tuxpoldo]

Is there a way to stop logging or move the logfile to /var/log/... when running in daemonmode? I need to redirect the logfiles to a ramdisk as logging is preventing my MyBookLive NAS from spinning down the disk

 

No.... But redirecting the log files do not solve your problems at all, since btsync does not only read and write to the log file but also to other files in the storage_path. If you want your hard disks to spin down, you cannot have any server tasks running, that access the disks on a regular basis...