Open valpet93 opened 2 years ago
Hi @valpet93 The guide is only required if you want to change the default way MISP workers are handled, I checked and the issue why the workers were not starting was a regression introduced by https://github.com/MISP/misp-docker/pull/140. Please pull the repo and try to build the containers again, workers should start without issues.
Let me know if this helps.
Hi @righel ,
First of all I would thank you for your patience.
Actually, the fix seems to fail as the output is quite similar:
misp_web | MISP is now live. Users can now log in.Starting supervisord
misp_web | 2022-07-27 13:37:57,951 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.
misp_web | 2022-07-27 13:37:57,958 INFO supervisord started with pid 1
misp_web | 2022-07-27 13:37:58,965 INFO spawned: 'apache2' with pid 75
misp_web | 2022-07-27 13:37:58,967 INFO spawned: 'misp-modules' with pid 76
misp_web | 2022-07-27 13:37:58,970 INFO spawned: 'master' with pid 77
misp_web | 2022-07-27 13:37:58,974 INFO spawned: 'redis-server' with pid 78
misp_web | 2022-07-27 13:37:58,977 INFO spawned: 'resque' with pid 79
misp_web | 2022-07-27 13:37:59,136 INFO success: misp-modules entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
misp_web | 2022-07-27 13:37:59,136 INFO success: master entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
misp_web | 2022-07-27 13:37:59,136 INFO success: resque entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
misp_web | 2022-07-27 13:37:59,536 INFO exited: master (exit status 0; expected)
misp_web | 2022-07-27 13:37:59,992 INFO success: apache2 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
misp_web | 2022-07-27 13:37:59,992 INFO success: redis-server entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
misp_web | 2022-07-27 13:38:02,508 INFO exited: resque (exit status 0; expected)
However, the post-fix exit status of both resque and master is 0, which is way better than before.
Any further idea to figure out the problem?
Do you have the same output in MISP diagnostics -> workers?
Actually no, they are good:
What's going on in there @righel ?
What the output of the sudo docker-compose up command is supposed to be like? By my side it seems to be not finished as no shell prompt is prompted in cli:
In addition, I tried to brutally shut down the machine (no Ctrl+C to the command) and restarted. The docker at the boot of the machine was already up with MISP GUI totally working along with all the workers.
However, is the supervisor supposed to be installed by the sudo docker-compose up command?
Hello, I'm not the original author of this repo but it works like this:
nodaemon
mode here: https://github.com/MISP/misp-docker/blob/master/web/run.sh#L145 in the docker-compose.yml entrypointThe issue you faced originally was the workers were trying to run as root and there's a check in the script that starts the workers that prevents this, see: https://github.com/MISP/MISP/blob/2.4/app/Console/worker/start.sh#L5
From what I can see it is the expected behavior for the master
and resque
programs to exit. The workers are spawned after start.sh
finishes execution, same happens with postfix, the daemon is also running after the master
program exits.
Hi there.
When I run sudo docker-compose up, supervisord is unable to start. It seems the problem is linked to postfix (master) and resque workers (see below).
I tried several times, installing the docker on ubuntu both server (22 and 20) and client (22 and 20).
However, the docker containers are up. I can log in to MISP GUI. There are no workers shown in diagnostic. Moreover, if I set supervisor to true, no settings page is reachable, as it is supposed since it is not up.
In addition, I'm able to access to docker container with sudo docker exec -i -t 50dfd5921cfe /bin/bash command. Those below are the output of several command to check supervisor status
However, I tried to figure out the issue, so I uninstalled any trace of supervisor
and installed it again following the official MISP guide with some tweaks (see below for an example): I changed the 28th line of the file /etc/supervisor/supervisord.conf from
to
Eventually, I succeed:
BUT whenever I restart the docker container, that keeps to report the same error reported at the start of the post, I have to stop and start supervisorctl service...
There is something broken in the installation script I suppose.
What can I do for you in order to fix it?
Below you can find the whole output of the docker-compose up command as encoded file.
docker-compose up output.txt
See you