AbsolutelyNoOne
-
Posts
11 -
Joined
-
Last visited
-
Days Won
1
Posts posted by AbsolutelyNoOne
-
-
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".)
-
I use this (http://code.google.com/p/spindown/) to spindown and monitor the disks. When i stop the deamon with your script disk accessing is stopped, when i start the deamon, disks are accessed again about every 10 seconds.
Running the deamon with btsync --config spins tje disks up every 10 minutes as programmed by the developers to scan for file changes.
So it's really start-stop-daemon's fault. I'll investigate why this is happening.
This is how I start it as a system job with ubuntu (last LTS version, couldn't remember number) using upstart.
1. Create btsync.conf on /etc/init.d/
2. file contains 2 lines:
# home in my setup is another hard drive.
start on mounted MOUNTPOINT=/home TYPE=ext4
# starts as non-root user
exec start-stop-daemon --start -c myuser --exec /home/myuser/btsync
3. this satisfies my needs.
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.
-
I tried your init.d script and it works, but it prevents the harddrive from spinning down. Every 10 seconds or so the disc is accessed.
When i start btsync manually, the disc is accessed every 10 minutes as intended by the sync app to check for file changes.
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)
-
How can i autostart btsync when i start the headless server on which i want to run btsync?
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
* The passwords should not be required in cleartext, instead password hashes should be supported (this should be enough to authenticate a user).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.
Also I found the configuration very unintuitive.* The program should create the directory ~/.btsync and default to that instead of .sync in the folder of the binary.
* The program should create a config file in ~/.btsync/config with sane defaults and use that if none is given
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.
Debian And Ubuntu Server Unofficial Packages For Bittorrent Sync
in Sync General Discussion
Posted
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!