I am using a bound volume on the Docker host to externalize the state of the TDB2 database, so I can destroy the jena-fuseki container, and recreate it, but still use the original datasets/models. Sometimes I encountered an intermittent problem with a TDBException on successive restarts. It said that the current server PID was not the same as the PID that locked the database, and so the server stopped. I think this is a safety feature build into TDB2 to stop multi-process updates.
Just above the fatal exception there was a warning, that it could not execute the "PS" command, and this appear to be associated with the lock checking process. I tried issuing the PS command from inside the container's BASH shell, but it did not recognize it.
I added a fix to the Dockerfile so that the "procps" package was installed:
change:
bash curl ca-certificates findutils coreutils pwgen \
to:
bash curl ca-certificates findutils coreutils pwgen procps \
and this appeared to fix the problem, but I need to do more testing.
I am using a bound volume on the Docker host to externalize the state of the TDB2 database, so I can destroy the jena-fuseki container, and recreate it, but still use the original datasets/models. Sometimes I encountered an intermittent problem with a TDBException on successive restarts. It said that the current server PID was not the same as the PID that locked the database, and so the server stopped. I think this is a safety feature build into TDB2 to stop multi-process updates.
Just above the fatal exception there was a warning, that it could not execute the "PS" command, and this appear to be associated with the lock checking process. I tried issuing the PS command from inside the container's BASH shell, but it did not recognize it.
I added a fix to the Dockerfile so that the "procps" package was installed:
change:
bash curl ca-certificates findutils coreutils pwgen \
to:
bash curl ca-certificates findutils coreutils pwgen procps \
and this appeared to fix the problem, but I need to do more testing.