Following up on T134205, we chose Electron via the [electron-render-service](https://github.com/msokk/electron-render-service) project as a browser-based PDF render solution. While this has worked well overall, we have also found some stability issues (see T159922). The stability issues seem to be related to the need for a virtual X server using xpra.
Now that the Reading team has decided on using generic browser-based rendering as part of their PDF render pipeline, we should look into improving the stability of the browser-based PDF render solution used.
### Switch to headless Chrome
In T166188#3325004 and following comments, we discussed using the now-landed native headless Chromium mode for PDF printing. Using Chromium 59 or larger, PDFs can be printed from the commandline using an invocation like this: `chromium --disable-gpu --headless --print-to-pdf=obama.pdf https://en.wikipedia.org/wiki/Barack_Obama`. Since this implementation is headless, no xpra is needed, which should avoid the race conditions we encountered with electron. For easy launching of Chrome and Chromium from node.js, there is https://github.com/GoogleChrome/lighthouse/tree/master/chrome-launcher.
In order to expose a secure and reliable service, we would probably want to:
- Start one Chrome instance per request. Startup overheads seem to be around 100ms, which is not too critical given that median PDF render times are around 1s. A clean instance per request allows for reliable resource limiting.
- Limit resources used & accessible to a given Chrome process:
- Wall clock time
- Ideally, no writing to disk
- Ideally, run in firejail with all non-essential features disallowed.
- Stream out the returned PDF.
- Get to use regular Chromium package instead of binary electron distribution.
- Less complex.
- Chrome process per request offers better isolation.
- Need to write basic service wrapper.
### Resolve xpra race condition
Idea: Start xpra as a separate systemd service, and make the pdfrender service depend on that.
- Relatively simple
- No need to create service, or change consumers.
- Continued dependency on Electron, which is less maintained than Chromium.
- Reliability in the face of Electron failures (OOM) likely still less than perfect.