Required nodejs version?

MineOS-on-distro
1

What is the required version of node.js? I’m running a MineOS server on Fedora 22 but it still has node.js 0.10.36 because of the complexities with V8.

I’m seeing a lot of “quirkiness” and wonder if it’s due to the older version of node.js? I see things like this in the log:

"TypeError: Object #<Object> has no method 'parse'","    at EventEmitter.<anonymous> (/usr/games/minecraft/server.js:121:26)","

If a newer version would work better, I don’t want to override my system install, how would I go about a parallel install?

I downloaded the latest prebuilt stable version and extracted it into /opt/node-v5.1.0-linux-x64.

Looking through the minecraft directory I would need to replace every instance of /usr/bin/node with /opt/node-v5.1.0-linux-x64/bin/node at a minimum. Also, would /opt/node-v5.1.0-linux-x64/bin/npm install work? Would it find the correct includes?

Thanks,
Richard

2

Documenting some ideas for posterity :smile:

Could “process.execPath” be used to propagate whichever node binary starts the originating script (in my case service.js) to the other scripts?

The other option is to use process.env to prepend to the path but my google-fu is failing me on how to do that.

Or a combination of both, if process.execPath is not already in the path, then prepend it to the process.env path.

Thanks,
Richard

3

The current minimum required version is 4.0.0, the stable release. 4.0.0 and above are now the only tested versions.

Some important changes have happened recently that necessitate this update, but the last available commit that works on 0.10.x is 499f439f28b17174a238d9fb2869cf43cc37047d.

MineOS will require it going forward, but more importantly your server will benefit from using Stable releases over the pre-release, so it’ll be good all-around!

4

Well that answers that question. Probably a good idea to add it to the README :smile:

Any idea what I can do about running node out of /opt?

I tried adding

process.env.path = '/opt/node-v5.1.0-linux-x64/bin' + ':' + process.env.path

Near the top of serivce.js and it seems it MIGHT have worked, I don’t know of a good way to tell…

Also, I have no idea if it’s picking up the /opt includes or system includes…

Thanks,
Richard

5

Ok, I need to do some long term testing but I THINK I got it working, I had to modify the path this way:

process.env.PATH = '/opt/node-v5.1.0-linux-x64/bin'+':'+process.env.PATH;

And temporarily add it to the path in shell while executing npm install so all the modules get built with the right version.

Thanks,
Richard

6

Here’s a proof of concept, I’m not sure if any of the variable names clash with MineOS. I’m guessing this would need to go in service.js and webui.js. It shouldn’t hurt to be in both since it checks to see if it’s already in the path first.

#!/opt/node-v5.1.0-linux-x64/bin/node

var path = require('path');

// Return the path of the node executable
var node_path = path.dirname(process.execPath);

// Get the search path and turn it into an array
var search_path = process.env.PATH.split(":");

// Determine if node_path is in the search path and add it if needed.
if (search_path.indexOf(node_path) == -1) {
    process.env.PATH = node_path + ':' + process.env.PATH;
};

console.log("Node path:   " + node_path);
console.log("Search path: " + process.env.PATH);

Thanks,
Richard

7

It seems you should be able to get the webui working without any changes to source code at all (namely .js files). This is the case when I was working with node.js via nvm, which puts node binaries not in #!/usr/bin/env node or /bin/node.

How are you running MineOS–rather, how is it started? supervisord? systemd? etc. Depending on what method you’re using, you should be able to modify just the startup config and it work.

For example, if you used supervisord, you’d make a single change here:

Or for systemd:

Basically, the hashbang (the first line you’re changing) is only relevant if you run the script not as an argument to node itself. Since all of the provided init scripts for running MineOS do run it as an argument, the hashbang is ignored and you can use any node version you want.

This also spares you from the inconvenience of having code deviate from the official repository.

8

I tried just changing the systemd Exec part first, but that didn’t seem to be enough, however, I think the root problem was building the modules with the correct version of npm…

I’ll take out my modification and see.

Thanks,
Richard

9

Ok, everything is working as expected! I wonder if the install instructions should be updated to explain how to deal with this.

10

I probably should find a place for it somewhere in the wiki, but in the big picture, you might be the first person (I’ve come across) who needed parallel versions of node and had the MineOS-required Node not at the standard bin location. So, the main instructions might not be the right place for it, since it won’t be relevant to the vast, vast, vast majority of users, but I hope I can find a place for it all the same that one can learn the solution more directly.

11

Is fedora the only distro with old nodejs? I just saw where they’re finally going to update to the LTS version in F24 but that’s not even released yet and won’t be for at least 6 months.

On a couple of unrelated notes…

  • Should the restart in the systemd service file be always? Or on-failure? Will mineos exist with code 0 during a failure?
  • I’m not sure it’s possible, but the kill mode should only be “process” for failures. If I do a “systemctl stop mineos” shouldn’t the servers be shut down as well?

Thanks,
Richard

12

Key Question: are you certain you have to install node in parallel and can’t just upgrade?

The wiki instructions I provide for MineOS on RHEL or CentOS uses nodesource as the means for updating yum to get a more modern version of node. I can confirm that the v5.0 that nodesource builds works without issue for MineOS.

Thus, you shouldn’t have to wait for F24 to get node v4.0 or v5.0–you can get it right now, through yum.

I think you’re right on the money with this one. on-failure seems to make way more sense here.

Not by design. While it seems clean that when the MineOS service closes, it gracefully takes down the servers…there’s a lot of unintended–and potentially hugely harmful–side effects that can happen with other process-exits. See related: Servers automatically restarting and nonresponsive UI - #15 by Zone

In the above-linked post, MineOS was crashing repeatedly due to an npm module failing to stat a file that was being edited via temporary files, rather than “in-place”. This caused hard-to-detect exceptions that crashed MineOS. This failure preceded a recent commit, though, where the killmode wasn’t set to process, and thus this error ended up crashing not only the webui (which restarted) but also the children it spawned (minecraft java instances) that it should not have taken down.

Admittedly, there’s still room for much more improvement in my understanding of systemd, but I want the truly important processes (minecraft servers) not to be at the whim of my coding.

There could be a case made for “well, if MineOS is being deliberately, gracefully taken down, then shutting down the minecraft instances, too, would be convenient and safe”–and this is true: but again, I don’t really want my webui to be so closely integrated that MineOS failures result in Minecraft shutdown (ungraceful at that), potentially resulting in world corruption or the like.

After all, if the killmode killed the child processes, they would be given…sigterm, sigint(?)–not what Minecraft wants (compared to “stop” and some time to flush).

13

Well, it depends if you’re OK with replacing the version provided by your distro. There are a lot of nodejs modules provided as well which I’m assuming would no long work? Or does the repository replace them as well? Distro’s like Fedora and Debian tend to avoid bundling.

14

It’s my understanding that if you were to use nodesource's installation script, it should be as transparent as just having additional repos available to yum. Node definitely wasn’t installed on my copy of CentOS6/7 by default, so I can’t say for certain, but I would suspect that this method will replace your v0.10 with v4.0 just as much as later will replace v4.0 with v4.1…v4.2…and so forth–all without additional intervention outside of yum