Yes, the US server VM ran out of memory and killed a process that didn't have an auto-restart in its systemd service file...
Should be up and running again. Those who used the latest master SHOULD have been automatically redirected to the European server which continued working :-) /D > On Apr 24, 2021, at 11:54 AM, Attilla de Groot <atti...@attilla.nl> wrote: > > Hi Dirk, > > Are there any issues with the backend today? I’m not able to sync either from > my desktop or mobile (also over 4G). > > > — Attilla > >> On 19 Apr 2021, at 22:58, Dirk Hohndel via subsurface >> <subsurface@subsurface-divelog.org> wrote: >> >> Hi Jason, >> >> Thanks for the feedback. Yes, the new DNS records now have much longer TTL >> and are therefore more likely to be cached. >> I also made some subtle changes to the logic when we first attempt to >> connect and actually try to start writing to the cloud that might make a >> difference there. >> >> /D >> >>> On Apr 19, 2021, at 1:50 PM, Jason Bramwell wrote: >>> >>> Many thanks as always. >>> >>> I used to see a ‘feature’ where the first attempt to load Subsurface would >>> fall back to using the local cache and i’d have to close/reopen Subsurface >>> to get it to connect to the cloud storage, Linux diagnosed this as likely >>> slow DNS lookup, very brief testing (I do mean very brief) seems to >>> indicate that this is no longer the save now and it ‘just works’. >>> >>> Jason >>> >>> Sent from Mail for Windows 10 >>> >>> From: Dirk Hohndel via subsurface >>> Sent: 19 April 2021 21:00 >>> To: Subsurface Mailing List >>> Subject: redundant cloud servers >>> >>> >>> Over the past couple of weeks I quietly moved the cloud server backend and >>> the authentication database out of my home network and back into the public >>> cloud. >>> The fact that apparently no one noticed and nothing broke was rather >>> encouraging :-) >>> >>> I then setup a second cloud server in the public cloud, this one in Europe >>> (actually, Frankfurt, Germany). >>> >>> A few minutes ago I merged a pull request that adds a couple of interesting >>> new features to both Subsurface and Subsurface-mobile: >>> >>> - geo based choice of cloud server (those in the Americas should end up >>> using the US server, everyone else should get directed to the European >>> server), which is intended to be completely transparent to the user. >>> I.e., unless you explicitly look for it, you shouldn't notice (or care) >>> which server you are using >>> - hot failover between the two servers (so if the server that you have used >>> before is unavailable, Subsurface and Subsurface-mobile should try the >>> other one - and the implementation makes it easy to add more servers if >>> that appears useful) >>> >>> The two servers are automatically kept in sync in the background. I can >>> create one extremely artificial case where there is a fairly short >>> (generally sub one second in my tests) window for a race condition. A user >>> would have to have two different devices that are synced to different >>> servers (for example because they took their phone with them on an overseas >>> dive trip), that have made conflicting changes to the dive log, and the >>> user would then have to cause a save to the cloud on both devices within >>> the roughly one second window. Forcing that race turned out to be fairly >>> hard because the mobile app does a few other things before storing the data >>> to the cloud - so for testing I ended up using two instances of Subsurface >>> and synchronized clicks... really -- not a realistic scenario. >>> >>> If this were to happen, I will get an automated email alert and fixing the >>> problem isn't really hard - but I wanted to give a full disclosure of the >>> issues that I am aware of. >>> >>> What would help right now if people tested all this. >>> So far I have not had the time to make new beta versions of >>> Subsurface-mobile, but as I said, it's actually easier to test on the >>> desktop. >>> >>> /D >>> _______________________________________________ >>> subsurface mailing list >>> subsurface@subsurface-divelog.org >>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface >> >> _______________________________________________ >> subsurface mailing list >> subsurface@subsurface-divelog.org >> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
