Exception during conversion can make the process hang about dangerzone HOT 3 CLOSED

Our original assumption was that if the container has exited, the conversion process should immediately exit as well, maybe with some small delay for some cleanups. So, we originally attributed this to a race condition.

We have noticed this happening in case of successful conversions, where indeed it's due to a race condition. If we wait a tiny bit before checking the conversion process' status, we will see that it has stopped.

Things are very different in the case of failed conversions due to exceptions in the host. In that case, what happens is:

1. The process in the container calculates the number of pages and width/height of each page.
2. The host process receives these calculations from stdout, and decides that a unit is out of bounds. In the case of the sample_bad_max_width.pdf document, it's the width.
3. The host process raises an exception, and from its perspective, the conversion is over. At no point have we terminated the process running in the container!
4. In the meantime, the container will continue working on the document, and write pixels to stdout.
5. At some point, the container will exit or we will kill it with docker kill .... This doesn't matter much, but what matters here is that Docker is very careful with the container's stdout. It does not want to lose it, and thus the docker run ... process will block until we have read every byte from the container.
6. Deadlock! Our termination logic does not read data from standard streams, nor does it terminate the docker process, so both process will remain stuck.
   • Thankfully, we force kill the conversion process after 15 seconds, so we do end up making progress.

from dangerzone.

Now that we know what's going on behind the scenes, let's answer the above questions:

1. In some error cases, our termination logic reports that the container does not exist, whereas the conversion process (docker run ...) still exists.

That's because the conversion process may still linger, until the parent has read all the data that the container has written.

2. Specifically for the failed conversion case, when that happens in the host, the conversion process seems to be stuck indefinitely, and we have to kill it.

The conversion process remains stuck, because the container has written lots of data to the stdout, and the host process has not read them.

from dangerzone.

How can we improve here? We can do the following:

1. Unconditionally kill the container once the conversion is over, and don't check if kill succeeded, since it's racy.
   • Log a warning if the container still exists after kill, since this is not racy, and not expected.
2. Gracefully terminate the conversion process after we terminate the container, since we at that point, we don't want to read its data.

from dangerzone.