Tag Archives: node

Troubleshooting puppeteer in WSL2

I’m working on a small project to generate image files from HTML using a web browser. This is something I’ve toyed with for a while, but never really dug into canvas far enough. Once I discovered the puppeteer package for node, the dream seemed suddenly within reach.

Everything was going along fine, until I got to the point of actually trying to launch the headless browser. Then my program started crashing with the message:

(node:4279) UnhandledPromiseRejectionWarning: Error: Failed to launch the browser process!
/mnt/c/Users/blair/git/image-gen/node_modules/puppeteer/.local-chromium/linux-818858/chrome-linux/chrome: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory

The message included a link to a troubleshooting guide, which did mention some tips for Windows, but that was the Windows GUI environment and I’m using Ubuntu 20.04, running under the Windows Subsystem for Linux (WSL2). That meant it was either fix it myself, fire up a VM, or install node under Windows (which would mean losing the node version manager tool).

One of my main reasons for doing Node development in Linux is the ability to use nvm. A VM is much too heavy a solution for my tastes, so I wanted to see if I could get it working. And off to Google I went.

Searching for the error message is my usual first step, but although it turned up plenty of other people having problems (plus a few open GitHub issues from several years ago), it didn’t offer any solutions. Finally, a search for “puppeter wsl2 libnss3.so” led to a comment on an issue from last June where someone got it running by installing a bunch of packages manually.

0ne of the nice things about WSL is if you break your installation badly, it’s fairly trivial to remove it and reinstall a new copy. So it was fairly low risk to try installing the missing pieces to see if I could get it to work.

The error message even gave me a starting point: “error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory.”

There’s a page at https://packages.ubuntu.com/ which allows you to search for which package a library comes from. I started by putting libnss3 in the keyword field and specifying focal (aka “20.04”) as the distribution, and began the iterative process of looking up the installing the missing packages, trying my program again, and then looking up the next failed package. Happily, all it took was a half-dozen tries before my script started working again.

Here’s the list:

libnss3
libatk-adaptor
libcups2
libxkbcommon0
libgtk-3-0
libgbm1

Full-disclosure: midway through, it occurred to me that the reason the packages were missing might be because WSL isn’t a GUI environment and therefore doesn’t have a browser installed. Running sudo apt install -y chromium-browser didn’t solve the problem, but it is possible that this installed some additional packages which I was then able to avoid installing manually.

Now to see if I can get it to render a page. 😀

Considerations for Hosting a NODE Application

Spotted a question on Dev.to basically asking “How do you put a Node application in production?” and thought I’d copy my response here.

I’ll preface this by saying that although I’ve dabbled with Node, I don’t have anything in production right now that uses it. That being said, the way a Node web application runs – as a long-running external application instead of a module that’s part of the web server – is familiar enough for me to feel comfortable with the general principles.

How to use Node in production is actually a fairly broad topic, and a lot of it depends on exactly what the application is trying to do. It’s probably going to be useful to do some reading on Dev’s #node tag, but here’s my best high-level guidance.

Architecture
So, what’s your Node app doing? Is it running a public web site? Responding to URLs for a publicly available service? Or is it an application that your front end application just calls for specific calculations? This impacts literally everything else.

Hosting
A commodity PHP host won’t cut it for Node. You’re going to need one which allows for long-running applications. Generally that means a custom VM, or perhaps something that just allows you to deploy containers. That doesn’t have to be Digital Ocean or Heroku, though they do have the kind of set up you’re looking for.

Front end web server
There’s no requirement for a traditional web server, but it’s a common configuration. You can add middleware to Express to serve up static files, but it’s generally faster (and already written) to use Apache, Nginx, or something else to serve up files and act as a reverse proxy for the specific routes your application is handling.

Ports
This is a bit of a low-level implementation detail, but seeing as how others have touched on it…. I believe Express defaults to port 5000, but you can set it listen on whatever you want. If you’re using a front end server, you’d let the front end server handle port 80 and 443. If Express is handling all the traffic, then the Node app will need to handle those ports instead. (And note, I’m only assuming you’re using Express, that’s not required for a Node app that responds to HTTP requests; it’s just a very popular solution.)

Development vs. Production
I find it’s helpful if, to the extent possible, the development environment matches the production environment. You won’t install a compiler or an IDE on the production environment, but if the production environment will have a front end web server, it’s helpful to have the same front end web server running in the development environment. (I highly recommend you read about “The twelve-factor app for more about this topic, and other helpful guidance.)

Deployment
Automate all the things.” This has nothing to do with Node. If you can’t automate everything, automate as much as you can. Can’t use Travis, Jenkins, or a similar Continuous Integration tool? Go with a shell script.

I have personal experience with deployments which took three hours per environment and tended to result in production outage because the deployment instructions were a 12 page Word document. Those same deployments dropped to three minutes and stopped breaking production once we wrote a script to handle the config file changes.