-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MQ console is not accessed after repeated MQ1 container launching - maybe bug #523
Comments
Seeing this issue too. I think signals.go needs to call /opt/mqm/bin/endmqweb when shutting everything down. If you open a terminal into the container and do that yourself before stopping the container, the web server comes back next time OK |
see this reported issue: #448 |
@ltorok hi there. Can you retry again by pulling the latest image from Please do let me know about what was the observation. Thanks, |
@khaki86 @sichapman could also please give above a try. |
Same error
|
@sichapman thank you for the response.
Cheers! |
Hi all, when you retry could you please add the below to the This is required to gather extra logs from the liberty server. Requesting you to share the container console logs afterwards. Thanks in advance, Cc: @arthurbarr |
@ltorok I am interested to know how you do this, mentioned in your comment.
What commands do you use? Would it be possible to paste the chain of commands you have run in command prompt to achieve the entire flow you have mentioned in comment 1? |
Same issue with latest MQ version: 9.3.3.0 / MQ level: p933-L230531 Always been running a custom MQ_QMGR_NAME I use docker-compose usually, but equivalent normal docker commands exhibit the same behaviour: A A The workaround I use of overriding the ENTRYPOINT to be my own shell script with these contents, allows: the web server to start ok even in the
(the above is just a slightly more elegant version of the workaround in #448 (comment)) So I believe my original suggestion above of (edit: I also use tini to ensure sigterm is actually passed into the workaround script) |
@sichapman thank you for inputs. Please note that it has been found out that this is an existing issue with the WAS Liberty server specifically for WSLs (Windows Subsystems for Linux). And having said that, we have already raised the concern to the Liberty support team and they have confirmed the same. And they will soon be rolling out their next release inclusive of fix to this. Which, then will be incorporated in IBM MQ and subsequently it will propagate to mq-container as well. This may happen in coming CD releases of IBM MQ. Please watch out. Until then, instead, you can try out the mq-container in non-WSL actual Linux platforms or any other virtual machines and you will not see the problem. Hope this information helps. Thanks, Cc: @arthurbarr |
* Remove ioutil dependency * Add IBM copyright to amicontained
@ltorok @sichapman @khaki86 please note that the issue wrt WSL & liberty web server has been fixed in IBM MQ v9.3.5. Please have a go with the latest version and let us know. Thanks! |
Yes it does seem to be fixed now |
@sichapman great! Thank you for confirming. |
@ltorok can you please close this issue since its fixed now? |
See this tutorial: https://developer.ibm.com/tutorials/mq-connect-app-queue-manager-containers/
Extract from logs of MQ1 container:
...
2023-05-04 16:55:30 2023-05-04T14:55:30.167Z Removing existing ServiceComponent configuration
2023-05-04 16:55:30 2023-05-04T14:55:30.168Z Starting queue manager
2023-05-04 16:55:30 2023-05-04T14:55:30.549Z Started queue manager
2023-05-04 16:55:30 2023-05-04T14:55:30.549Z Metrics are disabled
2023-05-04 16:55:30 2023-05-04T14:55:30.734Z Error 1 starting web server:
2023-05-04 16:55:30 Server mqweb is already running.
2023-05-04 16:55:30
2023-05-04 16:55:30 2023-05-04T14:55:30.734Z Error starting web server: exit status 1
...
The text was updated successfully, but these errors were encountered: