Hi there, this is for a release running on Windows, but it might apply to other environments too.
I was getting a file-in-use error when trying to update a release, and after a while discovered it was because epmd.exe wasn’t stopping with the rest of the application. I’m wondering if this is a bug, or if I’m doing something wrong here? If anyone has run into this and can point me in the right direction, it’ll be much appreciated.
Same issue here. Especially as I’m building nsis installers for the release it’s nagging as it pops open an error message window to the user, and they have to click “ignore”. Thought about disabling epmd for my release builds but would love to have a real solution.
No, by default, if you start named Erlang instance, there will be EPMD spawned as a separate background process. You can run your release with EPMD disabled, but then you will not be able to use distributed Erlang from within (at least not without some additional work), unless you are using OTP 24 which has most of the work already done and built-in.
Thanks for taking the time to answer! So if we’re only ever going to be running one instance of a phoenix app, would I be able to safely turn off EPMD for the release?
Alternatively, is there a deployment flow that would work for our use case and avoid the “files in use” type of error? Currently we’re just (trying to):
Stop the app
Remove the entire current release folder
Copy down the latest release folder
Start the app again with the new release
I suspect I could change something about that to make it work without removing epmd, because when I build on my matching Windows Server box it has no issues replacing the version (overwriting the release).
In general yes, but be warned it means you also won’t be able to get a remote shell in to it if you need to do some debugging or so. EPMD is designed to never stop for note, it is a central registry of running nodes, even if no nodes are running then something may want to receive events of when they start up so it still needs to stay running for that.
That’s definitely not the BEAM way. A new beam release means you can just copy it into the directory, it will have a new version number and all, then you hotswap to it (if you set up your data migrations properly, otherwise just restart the application VM in full, don’t even need to stop the VM to do it). That’s what I do, although on linux. Basically a release is the new version in the rel/<yourapp>/releases directory, The whole process of upgrading a BEAM program, if fully set up properly, means you have zero downtime, and over the past 6 years at my current job I have indeed had zero downtime except for a power outage that lasted almost a whole day years ago. But I never remove my old releases, I have every version going on back, I could probably prune them but they are small enough I don’t care and it’s nice seeing that history.
EDIT: Do note, if you want to upgrade the BEAM VM itself, then yes that means a rolling reload, there’s ar reason I only upgraded the BEAM like twice on the production server in the past 6 years… it’s probably time to do so again what with that nice new JIT in it…
Ah, that makes a lot of sense. Thanks for the info. I won’t need EPMD then, but I’d rather not remove it if I don’t need to.
This is on a school board server I’m not allowed to interact with (data privacy) so I was trying to have as simple of an update process as possible for their IT people. Hoping to be able to give them instructions to just download a folder and restart.
If I overwrite the release on the same version during the build, will they be able to copy just that folder (/rel/myapp/releases/1.0.0) without issue? I’m trying to only have one version on their server at a time to minimize confusion.
Or will I need to generate a new version folder - and if so will the command /rel/myapp/bin/myapp start use the latest version automatically?
The beam system by default runs whatever the latest version is. But no, on Windows you can’t easily overwrite in-use files (though if you shut it down first then sure you can, even if epmd is still running if you don’t want to overwrite it too).
The command way is of course recommended, and yes start will use the latest by default, but if you want simplicity you can of course just stop, overwrite the program data itself (or wipe if first so you don’t get leftover things), then load again.