tuxpoldo

Sure. You were. But anybody here using btsync has at least two computers. The majority of us, has lots and lots of computers... ;-) I'm using btsync on 8 workstations (each different from the other), 4 routers, 2 NAS, 12 servers.... etc. I would say, that this is the final answer to the problem. The OS of your NAS is "debianoid" enough to permit the installation of .deb packages but not "debianoid" enough to be compatible to real mean Debian in relation to the startup sequence. Since I have not such a NAS, I have no idea how to solve your problem. But looking at the file you posted, I have the impression, that your NAS boots up only in runlevel S. I would suggest to replace the line 20 0,1,6 2,3,4,5 /etc/init.d/btsyncwith 20 0,6 S /etc/init.d/btsyncIf this does not work, you should ask for help in a forum with people knowing more about the distribution running on your NAS.

I would suggest that the next time you have a problem and you ask for help in the forum, you start by telling us something about the system because this is really important ;-) At least from your last posting, we can learn some very interesting things that are absolutely relevant in order to understand your problem: You are running btsync on an ARM Platform You are running btsync on a LG NAS You are running a default instance There is no sync.log in /var/lib/btsync (that is the storage_path of a default instance) From 3 and 4 I deduce, that you are running an outdated version. Starting with btsync 1.2.x they changed the default handling of logging, and it was not working any more with the btsync server packages (See this thread for details). In order to get again log files in the storage_path, you must make sure, that the following versions of the packages are installed on your machines: btsync-common >= 1.2.73-1 btsync >= 1.2.0-1 From 1 and 2 I deduce, that you are not running a typical computer installed with a standard Debian or Ubuntu, but a NAS either running a Debian based OS provided by the vendor or a Debian based port for the device. In any case, it's possible that the startup of system services is implemented somehow differently from a standard computer installation. And since your manual start of btsync generated the message "Changing alignment setting for executing btsync" in the system log (I suppose that you verified that the message was created by your manual start by checking the timestamp of the message) and this message can appear only once in a boot lifecycle (the alignment setting stays active until the next boot), we know for sure, that on system startup there was no attempt to start the btsync service. And now I would say that you should try to find out the difference between an original Debian and the distribution running on your NAS in relation to how services are tagged to be started in certain runlevels. I would start by checking if the symbolic links to the run level startup directories were created successfully. Here an example from my local router running Debian Wheezy on an ALIX board: tuxpoldo ~ # ls -la /etc/rc?.d/*btsync*lrwxrwxrwx 1 root root 16 Nov 14 14:59 /etc/rc0.d/K01btsync -> ../init.d/btsynclrwxrwxrwx 1 root root 16 Nov 14 14:59 /etc/rc1.d/K01btsync -> ../init.d/btsynclrwxrwxrwx 1 root root 16 Nov 14 14:59 /etc/rc2.d/S03btsync -> ../init.d/btsynclrwxrwxrwx 1 root root 16 Nov 14 14:59 /etc/rc3.d/S03btsync -> ../init.d/btsynclrwxrwxrwx 1 root root 16 Nov 14 14:59 /etc/rc4.d/S03btsync -> ../init.d/btsynclrwxrwxrwx 1 root root 16 Nov 14 14:59 /etc/rc5.d/S03btsync -> ../init.d/btsynclrwxrwxrwx 1 root root 16 Nov 14 14:59 /etc/rc6.d/K01btsync -> ../init.d/btsyncIf the links are missing, something prevented the setup program to create them, and this would explain, why it is not running...

The logfile is stored by btsync in the storage_path and is named sync.log Instructions about how to enable debug logging can be found here: http://forum.bittorrent.com/topic/12658-if-you-have-syncapp-issue/ Postponing the service start does make sense only, if the service depends on filesystems mounted in a custom (non regular) way (e.g. not using automount) since by default btsync will be started after the whole base system and networking is up. If you have configured such a thing, you should also know how to manage all dependent things. If you play around with the boot sequence and start implementing your own things, you should try to learn as much as possible about the inner working of the init process in order to handle all the problems. This forum is not the rights place for discussing such topics. In any case you must try to understand, what happens on your machine: look at the system log to see if the init script throws an error when starting up btsync If you see no btsync related error during the startup sequence in the system log, you should look at the btsync log file in order to see, if btsync stops or crashes after the start.

Yes. The installation routine registers the btsync as default service (update-rc.d btsync defaults). Please check first, if your service starts if you are starting it manually (service btsync start). If it does not start, then you can't expect it to start at system startup. If a manual start works, you should find out, if there are some prerequisites that are not met during the startup phase (like parts of the filesystem not mounted by default...). You can find some more information about the startup of btsync in the system log. A second reason for the service to be down after startup, is that it crashed. You should look at the log file of btsync and in case activate debug logging in order to find out, if the service starts but then crashes.

It must be commented. Read the initial posting. And it works. But there are some limitations: Files that are already present, will not be changed. You have to to change the old files manually. Only newly created files will be created based on the new UMASK The UMASK is only a mask (and not a mode). The default UMASK is typically 0022 - that means that all objects created with 666 will become 644 and all objects created with 777 will become 755. By default applications create files with 666 and directories with 777. This results by default in directories with 755 and files with 644. By setting the UMASK to 0011 you will get directories with 766 and files with 666

DAEMON_UMASK=0011 More Info in the initial posting

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.confAnd 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.logHere 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 daemonTwo 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....

Released new btsync-user desktop package 1.11.0-1 with a few bugfixes and another fundamental change in the structure of the packages that permit separate releases of the btsync server package and the btsync-user desktop package. Furthermore the versioning scheme has changed, since it is not dependent any more from the version number of the BitTorrent Sync core releases. The btsync-user desktop package will start it's own versioning with version 1.11.0-1 and resemble the version of Mark's btsyncindicator applet included in the package. Both Debian and Ubuntu builds are online on debian.yeasoft.net - The Ubuntu builds on Launchpad will be probably available in 2-4 hours . If you are Ubuntu User and prefer to switch to the debian.yeasoft.com repository, you should delete the file tuxpoldo-btsync-precise.list in your /etc/apt/sources.list.d directory and follow the instructions in the initial posting. And here the change log: btsync-user (1.11.0-1) unstable; urgency=low * Separated source from server version (Closes #38) * New upstream release 0.11 of btsyncindicator * Added missing dependency from python-gtk2 (Closes #39)-- Leo Moll <leo.moll@yeasoft.com> Sat, 16 Nov 2013 11:24:04 +0100

Released new btsync server package 1.2.0-1 with a few bugfixes and another fundamental change in the structure of the packages that permit separate releases of the btsync server package and the btsync-user desktop package. Furthermore the versioning scheme has changed, since it is not dependent any more from the version number of the BitTorrent Sync core releases. The btsync server package will start it's own versioning with version 1.2.0-1 Both Debian and Ubuntu builds are online on debian.yeasoft.net - The Ubuntu builds on Launchpad will be probably available in 2-4 hours . If you are Ubuntu User and prefer to switch to the debian.yeasoft.com repository, you should delete the file tuxpoldo-btsync-precise.list in your /etc/apt/sources.list.d directory and follow the instructions in the initial posting. And here the change log: btsync (1.2.0-1) unstable; urgency=low * Separated server from desktop package in order to permit separate releases (Closes #38) * Added debconf support for all advanced settings (Closes #36) * Fixed missing logfile generation broken with new btsync version 1.2.67 (Closes #40) * Added support for configuring verbose logging in the configuration file using DAEMON_DEBUG= (Closes #44) * Substantial improvements in error detection and reporting of the daemon init script. * Added Galician translation to debconf templates contributed by Miguel Anxo Bouzada (Closes #35) * Added Spanish translation to debconf templates contributed by VCLL (Closes #26) * Added Chinese simplified translation to debconf templates contributed by Julian (Closes #43)-- Leo Moll <leo.moll@yeasoft.com> Sat, 16 Nov 2013 17:26:58 +0100

Posted to syncapp@bittorrent.com in order to make it appear in the official bug list:

The problem still persists with Version 1.2.73 - kos13: Anything new? It does not crash immediately by invoking --help or --dump-sample-config but shortly after starting up with a regular config: tuxpoldo ~ # /usr/lib/btsync/btsync-daemon --nodaemon --config /etc/btsync/serversync.confBy using this application, you agree to our Privacy Policy and Terms.http://www.bittorrent.com/legal/privacyhttp://www.bittorrent.com/legal/terms-of-usetotal physical memory -1 max disk cache 2097152Using IP address 192.168.2.101Loading config file version 1.2.72Loaded folder /mnt/data/tftproot/yeabootError while adding folder /mnt/data/tftproot/yeaboot: Selected folder is already added to BitTorrent Sync.Illegal instruction

All packages online now will check if the alignment setting must be changed before invoking the executable. The package btsync was already doing this in the init script. The package btsync-common did it not, and so it failed to install on machines with than problem if the value was not set. This has now been corrected.

Thank you for your help. On Service startup there is already a routine that checks for the bad alignment and fixes it if needed. The problem was in the installation routine of btsync-common. See https://github.com/tuxpoldo/btsync-deb/issues/45 - I will add a fix in the next version of the btsync-common package... This should not happen again...

Linux Version: Reload settings from configuration file when SIGHUP is receivedReload logging debug mask from ${storage_path}/debug.txt when SIGHUP is receivedProvide some more command line parameters to override default logging options:--log stdout logs to standard output --log file logs to the standard file ${storage_path}/sync.log ALREADY IMPLEMENTED IN 1.2.73 --log file://var/log/btsync.log logs to a specific file --log syslog logs the local syslog with predefined priority(user) and tag(btsync) --log syslog:server=<server>,port=<portnum>,priority=<prio>,tag=<tag> logs to syslog as specified with the supplied (all optional) parameters

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

And thank you very much for making the logging feature work again also for my packages ;-) Obviously I would like also syslog support, but this could be achieved later on...

Same for me ;-) - I'm only wondering about the Permission denied error... But this is not interesting since on qemu it runs. It is really interesting to know, how this behaves on the NAS... But please let me know, which kind of NAS this is (Manufacturer, Model)

Something about the hardware. In any case I have two theories about what may go wrong on your machine. In the configure-phase the btsync-common package invokes the btsync executable in order to produce the sample configuration file saved together with all other documentation files. Nowadays we know that there are at least two possible causes that prevent btsync to run on machines with the armel platform: Alignment The ominous missing symbolic link to ld-linux.so.3 The first issue was already resolven in the btsync package, but this is not enough, since the btsync-common package will be configured before... The second issue was reported a few days ago, and I'm working on a solution for the next release But you can help me by looking for the following things on your machine: Is there a file or symbolic link called /lib/ld-linux.so.3 on your machine? Try the following: sudo echo 2 > /proc/cpu/alignmentsudo apt-get isntall btsync-common and let me know the result...

This seems to be the real problem. Unfortunately there is no output but I think that I have an idea about what is happening... Please be patient. I will release in the next days a new package and we can try if it fixes the problem. In the meantime, please uninstall everything: sudo apt-get --yes --purge remove btsync btsync-commonBTW: on my armel squeeze test machine it works... root@debian:/etc/apt/sources.list.d# lsb_release -aNo LSB modules are available.Distributor ID: DebianDescription: Debian GNU/Linux 6.0.7 (squeeze)Release: 6.0.7Codename: squeezeroot@debian:/etc/apt/sources.list.d# apt-get install btsyncReading package lists... DoneBuilding dependency treeReading state information... DoneThe following extra packages will be installed: btsync-commonThe following NEW packages will be installed: btsync btsync-common0 upgraded, 2 newly installed, 0 to remove and 34 not upgraded.Need to get 3,527 kB of archives.After this operation, 5,554 kB of additional disk space will be used.Do you want to continue [Y/n]?Get:1 http://debian.yeasoft.net/btsync/ squeeze/main btsync-common armel 1.2.72-1 [3,480 kB]Get:2 http://debian.yeasoft.net/btsync/ squeeze/main btsync armel 1.1.82.1-3 [46.8 kB]Fetched 3,527 kB in 5s (697 kB/s)Preconfiguring packages ...Selecting previously deselected package btsync-common.(Reading database ... 28094 files and directories currently installed.)Unpacking btsync-common (from .../btsync-common_1.2.72-1_armel.deb) ...Selecting previously deselected package btsync.Unpacking btsync (from .../btsync_1.1.82.1-3_armel.deb) ...Setting up btsync-common (1.2.72-1) ...Setting up btsync (1.1.82.1-3) ...Starting P2P file synchronisation daemon(s)...root@debian:/etc/apt/sources.list.d#Can you please give me some more details?

The command creates a symbolic link in the directory /lib pointing to a file located elsewhere. That means: instead of accessing the library by calling it /lib/arm-linux-gnueabihf/ld-linux.so.3, the application can also find it calling /lib/ld-linux.so.3. On my Raspberry PI running under Raspian, the following symbolic Links exist by default: pi@raspberrypi ~ $ ls -la /lib/ld-linux*lrwxrwxrwx 1 root root 30 Feb 23 2013 /lib/ld-linux-armhf.so.3 -> arm-linux-gnueabihf/ld-2.13.solrwxrwxrwx 1 root root 24 Dec 15 2012 /lib/ld-linux.so.3 -> /lib/ld-linux-armhf.so.3The effect is that if you access /lib/ld-linux.so.3 or /lib/ld-linux-armhf.so.3 you will always redirected to /lib/arm-linux-gnueabihf/ld-2.13.so As you can see, this is slightly different as the workaround specified by schlegel11, but the effect is the same: there will be a library named ld-linux.so.3 in /lib Basically you should find out where the library really is located and what is it's name on your system. Then you will create the symbolic link.

If you deleted btsync-agent.desktop from /etc/xdg/autostart I can tell you, that this was only a symbolic link: leo@ubupoldo:/etc/xdg/autostart$ ls -latotal 120drwxr-xr-x 2 root root 4096 Nov 6 17:41 .drwxr-xr-x 4 root root 4096 Oct 2 12:20 ..-rw-r--r-- 1 root root 305 Apr 4 2013 at-spi-dbus-bus.desktop-rw-r--r-- 1 root root 407 Mar 8 2013 bluetooth-applet.desktoplrwxrwxrwx 1 root root 44 Nov 6 17:41 btsync-agent.desktop -> /usr/share/applications/btsync-agent.desktop-rw-r--r-- 1 root root 369 Mar 28 2013 deja-dup-monitor.desktop The original file is saved in /usr/share/applications Please make a test with this NoDisplay=false - if it is displayed in a startup manager, it would be better for anybody. In order to edit the file in /usr/share/applications/btsync-agent.desktop you must be root: sudo nano -w /usr/share/applications/btsync-agent.desktop

pkill btsync

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...

OK - this seems to happen in some cases. In the forum, you will find several users telling similar stories. In this case I would say, that this is a problem of btsync itself...

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.confIn 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.confYou 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.... OK. I missed this....