Diskspace usage increate after restart

[tawaren]

For our testing environments we run janssen in docker over the monolith.
While doing so we run into disk usage problems. We realized, that each time the janssen container is stopped and then started again the disk space it needs increases by a few hundred MB's. If we restart ofthen we need from time to time make a complete reset (remove container and volumes, which then leads to rerun of the instalation scripts). I wanted to know if this is a known behaviour, if so if their are other counter measures then reinstall and if Kubernetes deployments will have the same problem or if it is monolith specific?

[tawaren]

I could figure out that it seems to be the /opt/jetty-11.0 folder that grows, 80% of it is in the /opt/jetty-11.0/temp folder.
If I find a easy way to clean it up on a stop or start I will share it.

[ossdhaval]

Thanks. That would be helpful 👍

[nynymike]

BTW, the monolith is just for testing. We have no such issues with a proper cloud deployment.

[tawaren]

Yes I know that the monolith is just for testing. We use janssen as part of an applied research project (we are a university) and making the result production ready is out of scope (will be done by someone else) and the version we deliver is a proof of concept running on a single machine. And janssen is just a small part of it. Currently we have one docker compose with all our own components + janssen + a nginx to route traffic to the right components.

[tawaren]

I did two small things to prevent container size growth after a restart (or stop/start)

1. I adapted the command to clear the /opt/jetty-11.0/temp folder (I did in the docker compose but the dockerfile would be preferable)
   command: bash -c "rm -rf /opt/jetty-11.0/temp/*;exec /app/scripts/entrypoint.sh"
2. I mapped the logs in addition to the custom folder to the host so i can easily delete (and inspect) them.
   volumes:
   • ./jans-log/auth:/opt/jans/jetty/jans-auth/logs
   • ./jans-log/config-api:/opt/jans/jetty/jans-config-api/logs
   • ./jans-log/scim:/opt/jans/jetty/jans-scim/logs
   • ./jans-fido2-log:/opt/jans/jetty/jans-fido2/log

The second only contributes minimally to the size grows, but having easy access to the logs from the host is something I want to be able todo anyway.

[tawaren]

I don't know if their is interest in this, but another thing rougly related to this was how the monolith behaved on a down/up.
On the fisrt up janssen monolith runs the install, this includes setting up the database. On the first down the container is removed (and thus the changes made by the install), the database however uses a volume which is kept. On the next up the install runs again but fails, because it tries to insert entries into the database that already exist.

I wrote wrapper scripts around down and up.
down:

• before the down command it checks if their is a /janssen/deployed file in the container and that their is no image called after-install-jans:${JANS_VERSION}
• if both hold it stops the jans container and commits a image of it named after-install-jans:${JANS_VERSION}

up:

• before the up it checks if their is a image called after-install-jans:${JANS_VERSION}
• if this holds it sets the environment variable JANS_IMAGE to after-install-jans:${JANS_VERSION}
• if this does not hold it removes the database volume and sets JANS_IMAGE to ghcr.io/janssenproject/jans/monolith:${JANS_VERSION}
• export the JANS_IMAGE variable

yaml:

• The jans service uses the image ${JANS_IMAGE}

My scripts are currently specific to our setup but if their is an interest in this I can extract the relevant parts and generalize them so that they work with the default monolith setup and share them.

[ossdhaval]

Looping in @moabu to get his comments

[moabu]

@tawaren can you open a PR with the proposed changes and link this discussion . I will be more than happy to review them and if they make sense which I think they do atm we will review the requested changes test them and merge them in.