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).