Salt API Exiting at Startup with Docker Compose
jasondalycan opened this issue · comments
Describe the bug
When starting with docker compose up, trying to connect to http://localhost:3333 results in connection closed immediately. Looking at the docker compose logs saltapi is exiting almost immediately.
To Reproduce
cd docker ; docker compose up
Expected behaviour
The application starts up and visiting http://localhost:3333 produces the UI
Screenshots
See the docker compose logs:
[root@saltmaster01 compose]# docker compose up
[+] Running 1/1
⠿ Container compose-saltmaster-local-1 Created 0.1s
Attaching to compose-saltmaster-local-1
compose-saltmaster-local-1 | 2022-08-05 20:33:31,268 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message.
compose-saltmaster-local-1 | 2022-08-05 20:33:31,268 INFO Included extra file "/etc/supervisor/conf.d/supervisord.conf" during parsing
compose-saltmaster-local-1 | 2022-08-05 20:33:31,275 INFO RPC interface 'supervisor' initialized
compose-saltmaster-local-1 | 2022-08-05 20:33:31,275 CRIT Server 'unix_http_server' running without any HTTP authentication checking
compose-saltmaster-local-1 | 2022-08-05 20:33:31,275 INFO supervisord started with pid 7
compose-saltmaster-local-1 | 2022-08-05 20:33:32,279 INFO spawned: 'saltapi' with pid 9
compose-saltmaster-local-1 | 2022-08-05 20:33:32,283 INFO spawned: 'saltmaster' with pid 10
compose-saltmaster-local-1 | 2022-08-05 20:33:33,303 INFO success: saltapi entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
compose-saltmaster-local-1 | 2022-08-05 20:33:33,303 INFO success: saltmaster entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
compose-saltmaster-local-1 | 2022-08-05 20:33:43,013 INFO exited: saltapi (exit status 0; expected)
compose-saltmaster-local-1 | 2022-08-05 20:33:43,013 INFO exited: saltapi (exit status 0; expected)
See telnet log:
[root@saltmaster01 compose]# telnet localhost 3333
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
Additional context
Add any other context about the problem here.
I replaying the situation.
docker compose up starts all 4 containers.
all (or most) containers produce massive logging about missing hostnames. this is a known situation as hostnames only become available after the corresponding container has started.
after several seconds the situation stabilises and also, I'm then able to open SaltGUI on port 3333 and login. the 3 supplied minions have announced themselves and are waiting for their key to be accepted.
so, for me it is working fine.
but when I initially tried it with an older edition of docker-ce on my Debian 11.4, both the salt-master and one of the salt-minions went down. instead of investigating, I first upgraded to the latest available docker-ce (20.10.17). after that I had no more problems.
I guess your version is even newer, because you are referring to docker compose (compose is built-in), while I must still use docker-compose (compose is a separate program).
can you please make sure that you are using the latest available version of docker for your platform?
please look at the output of docker compose ps. did any of the containers crash or exit?
when the problem remains, can you please upload the output of docker compose logs?
one common cause for failures with this docker setup is that salt-master and/or salt-api are already running on the host, thus blocking the ports.
I just realized that you did not start docker compose with -d and that therefore all output was already shown.
Can you take a look at file /var/log/salt/api in the 'saltmaster` container?
(salt-master and salt-api run together in one container)
I see what the issue is, I copied docker-compose.yml to another (empty) directory and ran docker compose up from there. Looking at the git cloned directory there are configuration files that the started containers depend on (i.e. rest_cherrypy config in the master file). I didn't realize that this config was required (thought the container would auto-create a default config).
Ok it's running now if I run directly from the git cloned directory. Thanks for the replies. cheers