One of the projects I’m tinkering with at work right now is a reporting system written in R. It’s built on Shiny, RStudio’s web application framework, a tool I’ve previously used for both the reasonable (reporting systems!) and nightmarish (mobile-optimised personal website in 40 lines of R).

To make deployment easier, we’ve been wrapping it in Docker, a common containerising system…with some godawful configuration settings that make it hard to debug the apps it encloses. Specifically, logs are (a) not immediately, obviously accessible and (b) just vanish.

After a week of frustrations I’ve finally worked out how to get around it, and thought I’d write it up. So we’ve got two things:

1. How to get access to the instance at all, so you can grab the Shiny logs, and;
2. How to grab the logs in a way that doesn’t lead to them magically disappearing on you.

Instance access

When you launch a docker image containing Shiny, you end up with a terminal full of the standard Shiny gunk:

This is nice and all but doesn’t let you wander around in the image without terminating the Shiny apps. There are a couple of ways to spin up a new terminal window for this - the easiest is with Kitematic, a (beta) Docker GUI that comes with Docker itself and is accessible via the dropdown menu:

When you load it up you’ll see a menu of current and past docker instances. Tabbing to your current one gets a screen like this:

From which you can launch (with the exec button) a terminal! A really crappy terminal. But a terminal!

Log access

Shiny’s application logs end up under /var/log/shiny-server/. So far, so standard. If you go there while a session’s running, you’ll see a file of the form shiny-big-long-uuid-so-long-omg.log. The problem is that when the session ends, the log is instantly removed. In other words, if what you’re tracking down is a bug that causes a session to terminate, your logs will register whatever the issue is and then promptly obliterate themselves.

The answer: instead of using cat or something to look at the log files after the fact, you can use tail (with the -f parameter) to have the logs streaming to you as they’re written. At that point it doesn’t matter if the logs then delete themselves because you already have whatever error you were tracking down. So:

1. Spin up the Docker image
2. Start a shiny session in your browser
3. Open a terminal to the instance through Kitematic
4. Navigate to the log directory and tail -f whatever-file-is-for-your-session.log
5. Reproduce the bug that causes the session to terminate
6. You have error reports!

And now you can track down the bug, a stage it took me to get three days to reach. Yer welcome.