syahra712 commented on issue #138: URL: https://github.com/apache/solr-orbit/issues/138#issuecomment-6325452069
Good call. I tried the options locally (Docker Desktop on macOS, `solr:9`, JDK 17) instead of guessing: | | How files get out | What broke | |---|---|---| | **Bind mount** | Directly on the host | Worked on macOS. With a host dir owned by uid 1000 and Solr running as 8983, which is what native Linux/CI gives you, writes fail with `Permission denied`. On top of that, SELinux (`:z`) and Windows path translation each need their own handling. | | **Named volume** at `/var/solr/logs` | Still needs `docker cp` or a helper container, since on Mac/Windows the volume lives inside the VM | `/var/solr/logs` doesn't exist in the image, so Docker creates the empty volume root-owned. Solr then refuses to start with `Logs directory /var/solr/logs is not writable`. You can work around it, but it needs a chown helper plus volume cleanup, including after crashes. | | **No volume:** `docker stop`, then `docker cp`, then `docker rm` | `docker cp` from the stopped container | Nothing broke. Solr shuts down in about 1 s, and the JFR is flushed on exit (`profile.jfr` goes from 0 B to 1 MB after the stop). The copied files belong to the user running solr-orbit, not 8983, so there are no host permission issues. | So I'd go with the last one. It never writes to a host path from inside the container, and it doesn't need any volume lifecycle. The current launcher uses `docker run --rm` plus `docker rm -f`, so both of those change: drop `--rm`, and make `stop()` do `docker stop`, `docker cp <name>:/var/solr/logs <test-run>/telemetry/`, `docker rm`. `start()` already does `rm -f` on a stale container with the same name, so a crashed run doesn't block the next one. A side benefit is that `solr.log` gets saved with the run as well. Two findings that affect `heapdump` on Docker: - `solr:9` is a JRE image, with no `jmap` or `jcmd`, so the current `docker exec ... jmap` can't work there. - `node.pid` comes from `docker inspect .State.Pid`, which is the PID on the Docker host or VM (1324 in my run). Inside the container the JVM was PID 14. For Docker I'd look for `jcmd` in the container. If it's there, use it with the in-container PID. If not, log one clear warning instead of a silent failure. PR split: 1. #143: jfr/gc/jit for `from-distribution` and `from-sources`, which doesn't touch Docker storage. I kept Docker out on purpose. Today the flags would point at host paths, and the JVM in the container exits on startup (`Error opening log file ... Could not create the Java Virtual Machine`). 2. Next: Docker via stop/cp/rm as above, plus heapdump before stop for all three pipelines. I'll pick this up once you're OK with the approach. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
