Over a million developers have joined DZone.

Why is a 32bit Windows Azure WebSite Running as 64bit?


Yesterday I updated my Ghost installation on Azure Websites and my test blog stopped working: I enabled error logging and the error I got was:

ERROR:[39m [31m Cannot find module './binding\Release\node-v11-win32-x64\node_sqlite3.node' [39m

Error: Cannot find module './binding\Release\node-v11-win32-x64\node_sqlite3.node'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (D:\home\site\wwwroot\node_modules\sqlite3\lib\sqlite3.js:7:15)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17) 

Ghost uses node-sqlite3 which is a binding toward sqlite and thus requires the native binary for the OS and architecture of the server: the download is done during the npm installation and depends on the architecture on which npm is running. In my case, since I have a free windows azure web site, the architecture is 32bit, so after installing the package I gotnode_modules\sqlite3\lib\binding\Release\node-v11-win32-ia32\node_sqlite3.node, which seems to be legit.

The dynamic reference is done based on the process.arch variable, so you would expect it to be ia32 as well, since my website is configured as 32bit. So why is the sqlite3 module trying to reference the x64 version?

I did some debugging through the amazing Kudu Debug Console to try and understand why: I tried getting the process.arch variable both via console (which should reflect the condition seen by npm) and via a small node.js app running in the same web site.

Running on the console node -e "console.log(process.arch)" I got ia32.

On the other end, trying to detect the same variable via the website I got x64.

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
}).listen(process.env.PORT, '');

Node-sqlite is behaving correctly: installing ia32 as npm runs under 32bit and requiring x64 as the website process is running 64bit.

Now I fixed my problem by running npm install sqlite3 --target_arch=x64 via the kudu debug console and forcing the installation of the 64bit version of the binary file for sqlite, but question still remains: why if the web site is configured as 32bit, the node.js process runs as 64bit while the console and deply process runs under 32bit?

UPDATE: I just installed the latest from Ghost master which references node-sqlite version 2.2 which changed binary dependency installation to node-pre-gyp. This installs the 64bit version of sqlite, so my problem is solved. Nevertheless, having the 64bit version when my web site is configured as 32bit seems a bug.


The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}