DB container and other services fail to start

[jlund]

Steps to reproduce:

1. Start a new VPS.
2. Follow the official self-hosting instructions.
3. Observe that ./server.sh start fails to successfully start the containers and ./server.sh logs shows the DB container crashing repeatedly (db-standalone exited with code 1).

The same issue occurs while trying to upgrade an existing server as well.

[owentrigueros]

Hi @jlund, how much RAM do you have available? I was in the same situation as you, both my existing server and the one I set up to check if a fresh installation didn't fail failed. It turns out that my server didn't have enought RAM. Works after upgrading from 1GB RAM+1GB swap to 2GB RAM+1GB swap.

The main change between the version I had installed and running and the current one is that there are two new services: workspace and workspace-worker, this may explain the problem.

[jlund]

Switching to a 4GB VPS and starting from scratch did indeed fix the issue. Resizing my existing VPS did not seem to work for some reason. Oh well, it was a good excuse to switch to a newer distro anyway :)

Thanks for the tip!

[christian-fries]

This is an important piece of information! I spent 2h trying to get standardnotes running on a new VPS with 2 GB of RAM (test instance) following the official docs but it didn't work. Assigning 4GB solved the issue.

The guide in the docs mentiones 2 GB of RAM, 1 CPU and Ubuntu 20.04 which does not work.

[owentrigueros]

CC @karolsojko

[karolsojko]

We’re in the middle of extracting a microservice for revisions history - a fix for the situation will be done soon. Sorry for the inconvenience.

[karolsojko]

Should be operational now

[jackyzy823]

If you keep extracting services to microservices , (though some microservices are optional ), it will raise the bar for selfhostng.

For selfhosting, each container of microservices may cost 200+ MB memory which is a waste of memory since these microservices share a lot of same components/libraries/code. and even worse each microservice is splited in to a server and a worker which doubles the memory cost.

For whom only have low memory, I recommend a method to make server and worker running in a same container.

    entrypoint: |
      sh -c "
      sed -i '/RedisDomainEventSubscriberFactory/  s/Redis)/Redis).duplicate()/' packages/<package-name>/dist/src/Bootstrap/Container.js   &&
      sed -i  \"/server.build/ a \ \ \ \ logger.info('Starting worker...');\\n\ \ \ \ const subscriberFactory = container.get(Types_1.default.DomainEventSubscriberFactory);\\n\ \ \ \ s
ubscriberFactory.create().start();\" packages/<package-name>/dist/bin/server.js &&
      ./packages/<package-name>/wait-for.sh db 3306
      ./packages/<package-name>/wait-for.sh cache 6379
      ./packages/<package-name>/docker/entrypoint.sh start-web
      "

Worker's redis connection will enter subscriber mode and can't be used by server at the same time , so we duplicate a redis connecion for worker. then we migrate worker code to server.

[eric-pierce]

@jackyzy823 if the SN install base does keep going down the microservice/worker route, it may be a good candidate for https://github.com/linuxserver to re-package as a single image

Looks like there are three threads discussing on the linuxserverio forums: https://discourse.linuxserver.io/t/request-standards-new-sync-service/3109 https://discourse.linuxserver.io/t/request-standardnotes-syncing-server/2620 https://discourse.linuxserver.io/t/request-standardnotes-web-sync/1955

[karolsojko]

@jackyzy823 @eric-pierce we are definitely going to have more microservices. As the domain grows bigger and bigger I can certainly say that this will the way forward. As we do share the love with our self-hosters, keep in mind we do have to keep in mind the performance of our applications on our infra for paid subscribers. I understand that hosting all SN microservices on one single machine can be resource consuming at certain stage, but unfortunately as the application grows bigger and has more responsibilities it is unavoidable to decouple the business domain into separate entities that can be scaled independently.