...

TODO figure out how to mount the sources & make them known to gdb.

Debug Qserv by Launching gdb From Compose

I'm not sure how useful this will be, but may have utility. I did it hoping to generate a crash dump in /qserv/data (a persistent volume) but it ended up changing behavior in a way (timing? init?) in a way that stopped a container from crashing/exiting on startup. 

You can have docker-compose launch a program in gdb. First you must build a new lite-build container with gdb installed; copy the relevant lines from the build container's docker file.

Add lines like this to the desired container:

    czar-proxy:
        command: gdb -ex=r --args mysql-proxy --proxy-lua-script=/usr/local/lua/qserv/scripts/mysqlProxy.lua --lua-cpath=/usr/local/lua/qserv/lib/czarProxy.so --defaults-file=/config-etc/my-proxy.cnf
        working_dir: /qserv/data
        cap_add:
          - SYS_ADMIN
          - SYS_PTRACE

Note the command starts with gdb, -ex=r (run the program without waiting for a run command), and --args (the executable and arguments to it). 

working_dir is the directory to run the program in, and cap_add  to add capabilities to the container, necessary for gdb.

Integration Tests

The integration test container is run separately from the docker-compose script. The primary benefit is that it allows you to have a separate docker volume that contains the test data, which does not get destroyed when bringing down your compose cluster with the -v (remove volumes) option. The secondary reason has to do with not deterministically knowing when qserv is running and ready for ingest. It's also been useful (so far during integration test development - this may change) to be able to re-run tests. 

...