Error trying to add modules

I get this error when trying to add modules during the tryton install:

Error "[0] ". Try again later.

I’m missing something obvious. But not obvious to me unfortunately.

Hi @BiliOslavi, welcome to the Tryton discussion. It is good to have you here!

To be able to help, we need some further information:

  • How exactly did you install Tryton?
  • How did you add the modules?
  • Which command results in the error message?
  • Is there an additional trace back (aka a long version) of the error message?

Hi Udono - thanks for the earlier reply.

  • Linux 6.6.30-gentoo x86-64 Intel
  • kernel mods for docker all passed (except out of date CONFIGs)

docker pull tryton/tryton
docker pull postgres

docker run --name tryton-postgres -e POSTGRES_PASSWORD=password -e POSTGRES_DB=tryton -d postgres

docker run --link tryton-postgres:postgres -e DB_PASSWORD=password -it tryton/tryton trytond-admin -d tryton --all

docker run --name tryton -p 8000:8000 --link tryton-postgres:postgres -e DB_PASSWORD=password -d tryton/tryton

http://localhost:8000/

  • language, admin info, config
  • add modules
    —> account (which pulls in several other modules)
    → activate
    Your system will be upgraded. …
    Then after a couple of minutes it comes up with Error "[0] ". Try again later.

That notwithstanding, I found that if I go back into the Administration menu and do the activation one module at a time from there, then things have mostly worked. Still plugging away on this, but I’m guessing the upgrade process overruns the memory available and chokes. Is it trying to install the modules in parallel?

I had similar issues when I gave my VM not enough RAM/CPU power. What hardware are you using?

I’m using an older x86_64 machine (i3-2100 CPU @ 3.10GHz) with 16Gb, but it’s running everything for Tryton under docker. So maybe the resource squeeze is in the docker layer.

I am also using docker, but on an Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz. What I have observed is that activating modules can take a long time in the Postgres Database, apparently because tables are altered; I even had to adjust the timeout value in my nginx reverse proxy, because otherwise the request could not properly finish:

proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_send_timeout 300;