FHT

Members
  • Content Count

    14
  • Joined

  • Last visited

About FHT

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Related (and link to another related post):
  2. +1 My use case is similar (if not the same), but I'd to phrase it in a different way. I want to be able to disable seeding of a specific folder on a device that has a connection which is either slow or expensive. It would be even better if this could be a default setting when sharing a folder from a super node. This sort of goes against the idea of distributed shahring that Resilio Sync/Torrents are, but I often want the robustness and reliability of a Resilio Sync transfer in a centralised sharing environment.
  3. Just for clarity, is rslsync running when this snapshot is restored? I assume it's not. I suppose the question could also be phrased as which files would need to be part of a snapshot to be able to make a Read Only peer be exactly as it was before Peer A removed the file? In this case if Peer A stays offline Peer B should have no way to know that the file was removed and serve it to Peer C. For what it may be worth, I recently moved the .sync folder on my "main" server into $HOME/.config/resilio-sync (for systemd sanity) and things were a bit wacky until I also moved `.SyncUser*` folders along with the various `.dat` and `.db*` files. If all of these are part of a snapshot I'm sure the time-travel will work.
  4. It's just odd when the Linux version's Web UI notifies you about an update every time you open it, gets you all excited for nothing. ☺️
  5. +1 (Ahh, the futility of a 4 year old feature request)
  6. I turned on debug logs. My ISP doesn't support IPv6, so those lines can be ignored. Right not there are no active peer transfers and this error appears to be part of a periodic task. Below is the part of the log that seems to happen every 3 or 4 minutes, but I don't think there's much more to be deduced from it except that it seems to be a tracker connection. Not sure why it wants to listen on a random local socket to connect to the tracker. Anyway, thanks for looking. [20170812 10:05:04.119] LF[3A06]: LicenseFolder::IsActive(consumer): return TRUE, personal license [20170812 10:05:04.119] LF[3A06]: LicenseFolder::IsActive(consumer): return TRUE, personal license [20170812 10:05:09.134] D! 14TrackerTcpConn::set_error[0x00007ff2c0ac8450][-1] 3 (No such process) [20170812 10:05:09.134] Closing uTP tracker connection to [2606:2e00:0:7c:225:90ff:fe47:76a6]:4000 - error 3 (No such process) [20170812 10:05:29.155] TRACKER[AF48] requesting peers from 173.244.217.42:4000 [20170812 10:05:29.155] Using existent uTP tracker connection to 173.244.217.42:4000 [20170812 10:05:29.155] Can't bind connecting socket 57 to IP 192.168.1.2:0 - 22 Invalid argument [20170812 10:05:29.155] D! 14TrackerTcpConn::set_error[0x00007ff2c0b31020][57] 22 (Invalid argument) [20170812 10:05:29.155] Creating TCP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 [20170812 10:05:29.155] Creating uTP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 [20170812 10:05:29.156] Closing TCP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 - error 22 (Invalid argument) [20170812 10:05:29.367] SD[AF48]: Got list of 2 peers [20170812 10:05:29.367] SD[AF48]: Peer 0 - id: 104**********************************25A [20170812 10:05:29.367] SD[AF48]: Peer 0 - addr: 172.***.20.116:61707 [20170812 10:05:29.367] SD[AF48]: Peer 0 - addr: 172.***.20.24:61707 [20170812 10:05:29.368] SD[AF48]: Peer 0 - addr: 192.168.1.22:61707 [20170812 10:05:29.368] SD[AF48]: Peer 0 - addr: 192.168.1.23:61707 [20170812 10:05:29.368] SD[AF48]: Peer 0 - addr: 192.168.156.1:61707 [20170812 10:05:29.368] SD[AF48]: Peer 0 - addr: 197.***.***.8:61707 [20170812 10:05:29.368] SD[AF48]: Peer 0 - addr: [2001:0:****:6abd:8:****:****:c7f7]:61707 [20170812 10:05:29.368] SD[AF48]: Peer 1 - id: 10D**********************************55B [20170812 10:05:29.368] SD[AF48]: Peer 1 - addr: 192.168.1.20:54107 [20170812 10:05:29.368] SD[AF48]: Peer 1 - addr: 192.168.56.1:54107 [20170812 10:05:29.368] SD[AF48]: Peer 1 - addr: 197.***.***.8:54107 [20170812 10:05:29.869] TRACKER[0958] requesting peers from 173.244.217.42:4000 [20170812 10:05:29.869] Using existent uTP tracker connection to 173.244.217.42:4000 [20170812 10:05:29.869] Can't bind connecting socket 57 to IP 192.168.1.2:0 - 22 Invalid argument [20170812 10:05:29.869] D! 14TrackerTcpConn::set_error[0x00007ff2c0ac8450][57] 22 (Invalid argument) [20170812 10:05:29.870] Creating TCP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 [20170812 10:05:29.870] Using existent uTP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 [20170812 10:05:29.870] TRACKER[D90B] requesting peers from 173.244.217.42:4000 [20170812 10:05:29.870] Using existent uTP tracker connection to 173.244.217.42:4000 [20170812 10:05:29.871] Using existent TCP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 [20170812 10:05:29.871] Using existent uTP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 [20170812 10:05:29.871] Closing TCP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 - error 22 (Invalid argument) [20170812 10:05:29.872] TRACKER[0165] requesting peers from 173.244.217.42:4000 [20170812 10:05:29.872] Using existent uTP tracker connection to 173.244.217.42:4000 [20170812 10:05:29.872] Can't bind connecting socket 57 to IP 192.168.1.2:0 - 22 Invalid argument [20170812 10:05:29.872] D! 14TrackerTcpConn::set_error[0x00007ff2c0b31020][57] 22 (Invalid argument) [20170812 10:05:29.872] Creating TCP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 [20170812 10:05:29.872] Using existent uTP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 [20170812 10:05:29.873] TRACKER[8B29] requesting peers from 173.244.217.42:4000 [20170812 10:05:29.873] Using existent uTP tracker connection to 173.244.217.42:4000 [20170812 10:05:29.873] Using existent TCP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 [20170812 10:05:29.873] Using existent uTP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 [20170812 10:05:29.873] Closing TCP tracker connection to [2606:2e00:8003:1:ec4:7aff:fe57:108e]:4000 - error 22 (Invalid argument) [20170812 10:05:30.083] SD[0958]: Got list of 0 peers [20170812 10:05:30.083] SD[D90B]: Got list of 0 peers [20170812 10:05:30.327] SD[0165]: Got list of 0 peers [20170812 10:05:30.327] SD[8B29]: Got list of 0 peers
  7. All settings are default, except bind_interface which is set to a real ethernet port (without it, docker and kvm virtual ports seem to get in the way). Listening port is not 0, I picked one and set my router to dst-nat it. As far as I can tell, things work normally and I don't think this causes the idle sync periods (the remote peer has only 2Mbps), but I'd still like to find out what this error is all about.
  8. I saw this line in sync.log: Can't bind connecting socket 59 to IP 192.168.1.2:0 - 22 Invalid argument The IP is that of the server running Sync. The connecting socket is, I think, coming from the 1 active remote peer (not in LAN). The peer does get data but it looks like the sync stops for a minute every few minutes. Is this something worth debugging further?