Frequently Asked Questions

Can ReproZip pack a client-server scenario?

Yes! However, note that only tracing the client will not capture the full story: reproducibility is better achieved (and guaranteed) if the server is traced as well. Having said that, currently, ReproZip can only trace local servers: if the server is remote (i.e., running in another machine), ReproZip cannot capture it. In this case, you can trace the client, and the experiment can only be reproduced if the remote server is still running at the moment of the reproduction.

The easiest way to pack a local client-server experiment is to write a script that starts the server, runs your client(s), and then shuts down the server; ReproZip can then trace this script. See Capturing Connections to Servers for more information.

Can ReproZip pack a database?

ReproZip can trace a database server; however, because of the format it uses to store data (and also because different databases work differently), it might be hard for you to control exactly what data will be packed. You probably want to pack all the data from the databases/tables that your experiment uses and not just the pages that were touched while tracing the execution. This can be done by inspecting the configuration file and adding the relevant patterns that cover the data, e.g.: for MySQL:

  - /var/lib/mysql/**

See Capturing Connections to Servers for an example using a local database and additional information.

Note that ReproZip does not currently save the state of the files. Therefore, if your experiment modifies a database, ReproZip will pack the already modified data (not the one before tracing the experiment execution).

Can ReproZip pack interactive tools?

Yes! The reprounzip component should have no problems with experiments that interact with the user through the terminal. If your experiment runs until it receives a Ctrl+C signal, that is fine as well: ReproZip will not interfere unless you press Ctrl+C twice, stopping the experiment.

GUI tools are also supported; see Can ReproZip pack graphical tools? for more information.

Can ReproZip pack graphical tools?

Yes! On Linux, graphical display is handled by the X server. Applications can connect to it as clients to display their windows and components, and to get user input. Most unpackers now support forwarding the X connection from the experiment to the X server running on the unpacking machine. You will need a running X server to make this work, such as Xming for Windows or XQuartz for Mac OS X. If you are running Linux, chances are that an X server is already configured and running.

X support is not enabled by default; to enable it, use the flag --enable-x11 in the run command of your preferred unpacker.


While displaying a UI through the X protocol works fine, applications using direct rendering (DRI) to access dedicated graphic hardware might not be reproducible: the libGL library packed with the experiment is often specific to the driver of the original machine, and therefore the machine where the experiment is being reproduced would need to use the exact same hardware and driver.

Please refrain from requiring direct rendering in applications that you intend to pack with ReproZip.

If using Vagrant, you can also use the virtual machine’s native display directly, by supplying the --use-gui option to reprounzip vagrant setup.

How can I access the generated system or virtual machine directly?

If you are running reprounzip vagrant, you can connect to the Vagrant virtual machine by running vagrant ssh or connecting via SSH to the destination listed by vagrant ssh-config (often localhost:2222). These commands should be run from inside the directory created by the unpacker.

If you are running reprounzip docker, you can inspect the Docker container directly by using docker, or start a new one based on the image created by reprounzip; all images generated by ReproZip are named with the reprounzip_ prefix. For more information on how to inspect and create Docker containers, please refer to the Docker documentation.

For reprounzip chroot and reprounzip directory, the filesystem is in the root subdirectory under the experiment path.

See Structure of Unpacked Experiments for more details.


Note that, in the generated system, only the files needed for running the unpacked experiment are guaranteed to work correctly. This means that you may have only parts of a software distribution (required to run the experiment), but not the software in its entirety (unless the complete software was included in the configuration file while packing). For example, you may only have a few Python files that the experiment needs, but not the ones required to run Python interactively or install new libraries. Therefore, do not expect that all the software components will run smoothly when acessing the system.

The utilities from the base system might also not work correctly (if they are not part of the experiment) because reprounzip overwrites the libraries with the ones from the original environment. In the worst-case scenario, the dynamic linker or the shell may not be usable. Note that some unpackers install /bin/busybox, which you may find helpful.

What if my experiment runs on a distributed environment?

ReproZip cannot trace across multiple machines. You could trace each component separately, but ReproZip cannot connect these multiple .rpz files to setup the multiple machines the right way. In particular, you will probably need to set up the same network for the components to talk to each other.