space-on-premises-space-1 exited with code 13
Whenever I try to start Space using Docker Compose, I get `space-on-premises-space-1 exited with code 13` as an error. This error did not appear until I moved the config outside of the volumes and changed it so I can access it without an SSH tunnel.
The log is located here.
Please sign in to leave a comment.
I have this problem too, but it doesn't happen always... Right now it works without problem, but sometimes when I restart the containers, it throws this error. A fix would be appreciated :)
Stampylongr Hi,
Did this error start appearing after additional customization of the Space instance? The logs indicate the below issue:
It is likely, the configuration files are corrupted (some secret keys were inserted incorrectly or syntax was changed). You may try to rename the existing
configs
directory, then generate a new one with the following command:docker-compose -p space-on-premises run --entrypoint=sh init-configs /prepare_default_configs.sh
. Once done, migrate all secrets from the old config files to the new ones.Hi,
I have the same issue. I started from a fresh installation using Docker Compose. Everything worked fine with the proof of concept. Now I tried to simply generate the config file locally, for the same reason as Stampylongr . I wanted to be able to access my Space without SSH tunnel. But I did not modify any of the config files, I simply modified the docker-compose.yml as explained in https://www.jetbrains.com/help/space/configure-space-for-docker-compose-production-environment.html .
I tried the proposed fix but now I get a new error:
Lucien Gremaud,
Could you please share the modified docker-compose.yml file?
I'm not Lucien, but I create a YouTrack ticket with this same issue. Here is my docker-compose.yml file:
Hello everyone!
This error may occur in situations where the installation was started with the masterSecret value in the space.on-premises.conf file set to one value and has since been changed to a new value, while the DB remains the same.
May I ask if you already tried to drop the database and start the installation from scratch, or revert the config to the initial values used on the initial start? Thanks!
Pavel Boger's suggestion worked.
There seems to be an issue with the space installation process, actually.
Pavel Boger
"This error may occur in situations where the installation was started with the masterSecret value in the space.on-premises.conf file set to one value and has since been changed to a new value, while the DB remains the same."
The above is an answer that all support staff is giving… But it doesn't seem to work of late at all
I've already logged a ticket on 20 August and another follow up tonight, and originally communicated with Oleg, but he's not responsive at all.
I've actually made a video of the customer experience… Pavel Boger can you please have a look and let me know if it's me doing something wrong… or escalate this so that it can be resolve:
https://www.loom.com/share/9956dd7f53484ddc89c27efd32912f2b?sid=d4de41f9-0e5f-4950-9323-c0a2177d9ba1
The ticket that I've logged is:
https://space-support.jetbrains.com/hc/requests/5438607
It's the same problem. Is there a solution?
I found a solution.
I hope it helps~
1. docker-compose -p space-on-premises down rm -f
docker-compose -p space-on-premises up -d
docker exec -it space:2023.2.0 cat /home/space/circlet-server-onprem/config/space.on-premises.conf | grep masterSecret
masterSecret value notes
2. docker-compose -p space-on-premises down rm -f
3. https://www.jetbrains.com/help/space/configure-space-for-docker-compose-production-environment.html#enable-customization-of-your-space-on-premises-instance in order progress
Apply the masterSecret value obtained in step 1 above to space.on-premises.conf and package.on-premises.conf.
hello, im facing the same issue, may Stampylongr or @... please describe the steps required to fix it?
thank you very much in advance
Hello,
We have discovered an issue with the masterSecret key used for the db connection. The solution posted by A above can be considered as a temporary solution for the 2023.2.0 version. The team is currently investigating the root cause of this issue. I will post an update as soon as possible.
Sorry for the inconvenience caused by this issue!
Just a correction here… You did not discover an issue… I reported this issue on 20 August (11 days ago) and up until now JetBrains were not aware of an ongoing P1. This is likely something to address as it poses significant risk to customers' business.
A further note why were breaking changes introduced (or any changes for that matter) without updating the version number?