AbsolutelyNoOne

After installing btsync in a new virtual machine I compared the configuration files. Mine has DAEMON_GID set up, so I decided to remove it and give a try. Now btsync is working as expected. Maybe I misunderstood the meaning of this variable, assigning my username. Also, it wasn't working on the other machine because I scp'ed this "faulty" configuration to save some time. Thanks for the support. Keep this good work up!

OK, I'm going to test it in a KVM virtual machine running Ubuntu 14.04. No collaborative session, though. Network policies of my company prevent me from doing this...

Actually, I don't think it's related to a specific version of Ubuntu. When I said it is happening for some time now, I meant to say it happens since the very beginning of the package deployment (I'm an "early adopter" of the packaged btsync). I'm not sure if I began using it with 13.04 or 13.10. The pidfile I'm deleting in order to get btsync working again is the one in storage_directory.

I have the btsync package installed in two machines, one is Ubuntu Server and another is Ubuntu Desktop, both 14.04. The btsync-daemon refuses to keep running after the machines are booted or when I restart the service. Right after restarting the service, its status is "running". A few seconds after, it's "not running". When I remove sync.pid and restart the service, it runs normally. This behavior happens on both machines and is happening for some time now. Any tips on this issue?

Yeah! I just noticed that. If any btsync developer is reading this... I'd like to ask why there's a Javascript redirection at the root. Doing this way forces me to have another nginx directive to control what is going to /gui/ because nginx only intercepts HTTP redirects... For now, this additional directive helps out, but we will lose the pretty /btsync URL... (we are still able to access /btsync but there will be a redirection to /gui) location /gui/ { proxy_pass http://127.0.0.1:8888/gui/; }

Great job! Installing it now on my two machines.

This piece of code works like a charm: location /btsync/ { rewrite ^/btsync/gui(.*) /btsync$1 last; proxy_pass http://127.0.0.1:8888/gui/; proxy_redirect /gui/ /btsync/; proxy_buffering off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } (LoL! I was writing a long post criticizing GUI's JS when I suddenly noticed that I wrote the "rewrite" statement with "break" instead of "last".)

So it's really start-stop-daemon's fault. I'll investigate why this is happening. Sweet! Despite the need to have a separate copy of btsync's binary, it's very simple and good to go! Upstart has its way to track the daemon's PID and I'm not sure if it can handle multiple PIDs. To run btsync for multiple users we need to specify two services, something like btsync-all and btsync-user. btsync-all is going to start a btsync-user for every user and let upstart control the PID generated in btsync-user instance. (I'm not an Upstart specialist, so I can be very wrong in this case) Another good thing to do is a safety check for all configuration files to prevent the execution of btsync if webui is enabled and the same port number appears in some of them.

This is weird but I believe that it's start-stop-daemon's fault, somehow. How you found that 10 seconds is the disk access interval? Running btsync --config from the command line shows the same symptom?

@lb1a, run "file btsync" and "uname -a" and post the results (tip: maybe you downloaded a binary of another architecture)

I adapted a init.d script to be used with BTSync in Debian environments (soon I'll write with an upstart version) - https://gist.github....lGusmao/5398362 I agree! Maybe Transmission's approach could be used: you put a cleartext password in a settings.json and when Transmission is ran, it detects if it's cleartext. If positive, Transmisson hashes the password then updates the file with the hash. I say more: btsync is considering the location of itself. When running from /usr/bin it'll try to use /usr/bin/.sync/. It sounds no good.