Xwiki:mariadb-tomcat docker always crashes when installing standard flavor

Help / Discuss
, ,
#1

I’ve installed xwiki:mariadb-tomcat using the docker image. When I first ran it, it took me straight to the wizard and eventually crashed while installing the standard flavor. I restarted the docker image and it took me to the wiki, but when I log in, it resumes the wizard where it left off. I might make a little progress on installing the flavor each time, but it keeps crashing and I have to try again and again. My hope is to demo this to my employer as a possible CMS, but I’m a little worried about reliability at this point without understanding the problem.

I’m relatively new to docker, so I’m not even sure where I’d find xwiki’s logs. docker logs doesn’t seem to be getting the debug output from the flavor installation.

I’d appreciate any help you can offer.

#2

Hi, can you provide more info on what you mean by “crash” and provides the logs of the xwiki docker image output (docker log <container id>)?

Thx

#3

I can, yes, but it’s not going to be very informative, as it never outputs anything new after it’s done booting. And by crashes, I means the docker container exits with no further output to logs.

xwiki.log (71.4 KB)

#4

It’s worth noting, btw, that I have tried installing the .deb package as well and run into a different problem there. Not sure whether I should address that in a separate thread or treat this thread as “whatever it takes to get xwiki working for me”.

#5

Note that it seems you’re not using the right way to stop XWiki. You should stop the docker image and not restart the webapp using Tomcat’s manager (see all the warnings in the logs).

I don’t see anything wrong in the logs though. The last start of the docker image has resulted in XWiki being started but no HTTP(S) request was made to it.

#6

Note that it seems you’re not using the right way to stop XWiki. You should stop the docker image and not restart the webapp using Tomcat’s manager (see all the warnings in the logs).

I don’t see anything wrong in the logs though. The last start of the docker image has resulted in XWiki being started but no HTTP(S) request was made to it.

That’s not me stopping the webapp. I don’t even know how to do that. The container just stops on its own.

I definitely am connecting to it, though. I can log in and browse the wiki (what little there is) before I log in and resume the setup wizard.

#7

I’m going to document the other two approaches I’ve tried to this. We’ll see if any of them sounds more promising.

Using docker-compose (GitHub - xwiki/xwiki-docker: Dockerfile to build and run XWiki on docker)

WARNING: The XWIKI_VERSION variable is not set. Defaulting to a blank string.
Building web
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/volfied/xwiki/Dockerfile: no such file or directory
ERROR: Service 'web' failed to build : Build failed

So obviously I need a Dockerfile, even though the instructions make no mention of one. So I grab the one from github and I get this error instead:

WARNING: The XWIKI_VERSION variable is not set. Defaulting to a blank string.
Building web
Sending build context to Docker daemon  15.87kB
Error response from daemon: dockerfile parse error line 41: unknown instruction: APT-GET
ERROR: Service 'web' failed to build : Build failed

At this point, I’m stuck.

Standard Installation (Installation using Debian (.DEB) packages (XWiki.org))

Everything seems to install properly, but when I open up the site, it fairly quickly generates the following error while initializing:

xwiki_error.txt (11.9 KB)

Hopefully something in here sounds easy to fix.

#8

Evidently the xjetty package on Debian 12 is sorta bleeding edge. I’ve chimed into this thread, since we’re having the same problem: 15.9 on Debain 12.2 with xjetty package, crashes with Error 500 - #4 by tmortagne

#9

I managed to get the deb package working, so I think I’m good.

#10

Hello @volfied

I’m fixing this to not require building an image, as it’s not necessary.

I’ll fix this too. The reason it didn’t work is because you didn’t edit the versions and kept the environment variables in the compose file. The doc us not very clear but says:

  • You can edit the compose file retrieved to change the default username/password and other environment variables.

I’m changing the instructions to not have this problem anymore.

1 Like
#11

Awesome. Thank you, Vincent.

#12

Fixed in Loading...

1 Like