Meteor 1.4 Module did not self-register is causing a 502 Bad Gateway

Excited for 1.4 but of course I’m having an issue with bcrypt which is coming from that binary dependancies alteration from https://guide.meteor.com/1.4-migration.html#breaking-changes

It says that “Some very common binary packages (such as npm-bcrypt) will already have been republished for the Node 4 platform” and its fairly true – it works fine (great) on El Capitan but I don’t see meteor making binaries in the BUILD process. I know the arch is different but I’ve poked around the mup source code and one of the first things it does is BUILD a bundle with --architecture os.linux.x86_64

I’m using MUP from https://github.com/kadirahq/meteor-up.

My mup.js file:

module.exports = {
    servers: {
        one: {
            host: 'hux.co',
            username: 'root',
            pem: '/Users/James/.ssh/id_rsa',
        },
    },

    meteor: {
        name: 'hux',
        path: '../../',
        servers: {
            one: {},
        },
        env: {
            ROOT_URL: 'http://hux.co/',
            MONGO_URL: 'mongodb://localhost/hux',
            PORT: 3000,
        },
        dockerImage: 'be84d9dab6fd',
        deployCheckWaitTime: 30,
    },
};

That dockerImage be84d9dab6fd is one of my own which was made on the test server (ubuntu host, meteorhacks/meteord:base dockerImage). I edited line 3 of install_node.sh from https://github.com/meteorhacks/meteord:

NODE_VERSION=4.4.7 // changed to 4.4.7

Then ran docker build . and it produced my beloved be84d9dab6fd

Finally…

Back on my El Cap dev station, after running mup deploy here is the error log readout:

[hux.co]Error: Module did not self-register.
[hux.co]    at Error (native)
[hux.co]    at Object.Module._extensions..node (module.js:434:18)
[hux.co]    at Module.load (module.js:343:32)
[hux.co]    at Module.Mp.load (/bundle/bundle/programs/server/npm/node_modules/meteor/babel-compiler/node_modules/reify/node/runtime.js:16:23)
[hux.co]    at Function.Module._load (module.js:300:12)
[hux.co]    at Module.require (module.js:353:17)
[hux.co]    at require (internal/module.js:12:17)
[hux.co]    at bindings (/bundle/bundle/programs/server/npm/node_modules/meteor/npm-bcrypt/node_modules/bindings/bindings.js:76:44)
[hux.co]    at Object.<anonymous> (/bundle/bundle/programs/server/npm/node_modules/meteor/npm-bcrypt/node_modules/bcrypt/bcrypt.js:3:35)
[hux.co]    at Module._compile (module.js:409:26)

My xcodebuild -version is Xcode 7.3 and I have tried deleted all traces of node_modules and rebuilding with meteor npm rebuild and bcrypt works fine on El Capitan.

1 Like

How does anyone else deploy 1.4? I’m at a loss. This is a huge problem with meteor

What version of npm-bcrypt is your app on?

I successfully deployed my app using older version of mup (pre mupx) with fix I needed to apply for Meteor 1.3.

Good question, it’s npm-bcrypt@0.8.7

Hey M4v3R I actually saw your PR when researching this…

https://github.com/arunoda/meteor-up/pull/942

I’ll see if I can edit the source code to install node v4.4.7 and give it a shot. Thanks for the PR :sunglasses:

I don’t know how you did it because using your PR I still can’t get it to work

I had an issue with npm-bcrypt that required deleting the package install before installing. Somehow not deleting did not let the package install properly.

See this stackoverflow thread.

gave up and switched to galaxy. works great but that price tag though…

I know that you’ve already resolved this, but I noticed that people had problems with mup when they switched Meteor versions while using the same server. My solution for that was to nuke the old deployment, uninstall node and remove ~/.node-gyp from the server, and then do mup setup and mup deploy again. Only after that it worked. Maybe that’ll help someone.

@M4v3R
Thanks! It works perfectly!

After 2 weeks with Galaxy, although I’m weary of vendor lock-in, it’s an astonishingly well-polished product. I’m sold for sure.

Anyone know how to deal with Mongo Observers? I will have a multi server setup soon, and I was wondering how we deal with that. Currently my Observers would run one time on each machine thats running and thats pointless- once is all I need.