I am currently seeing a weird error when using gatling and erlang/otp 20. Everything was fine
before the update and now I am getting this:
warning: redefining module MyApp.Mixfile (current version defined in memory)
** (Mix) Trying to load MyApp.Mixfile from "nofile" but another project with the same name was already defined at "/home/bitboxer/sign_dict/mix.exs"
I already commented on this issue in the Gatling repo, but without any progress so far. Now I want to understand what is going on to create a patch for this. But I have no clue what is going on. Can someone here help me debug this or point me a direction how to figure this one out? Thanks!
Do you have any .beam files lying around in the directory where you’re running from? It might be the case if you manually compiled some modules. The shell will by default load all such modules from the current directory.
There are no .beam files laying around. And compiling also works for me. I can compile just fine on the system that builds and deploys it. But running sudo --preserve-env mix gatling.receive sign_dict fails with the said error message. That’s the command gatling runs in the post-update git hook.
Just any time I see sudo in such a thing implies to me that something “Very Very Wrong” is happening, and that is immediately what I focus on when something is ‘unexpectedly not working’. Can you compile it at the very least without the sudo and its flags on that remote system?
EDIT: For more detail:
Running the entire command with sudo is going to change file permissions on what is compiled, change where things are located, among a lot more. If it is needing sudo to do something like alter system startup files (which I would have personally made a secondary generated script that could be sudod explicitly instead of everything) then it should not be doing anything else, but mix at the very least is going to compile and check files and so forth, which if the system then later tries to start the build as another user from the init system then it could be using those generated files that were generated as root, which I could see causing an issue like this.
In essence, any ‘deployment’ parts that need root should be a secondary script (generated or not, could be escript or shell script or whatever, just notmix), because mix should never ever ever be run as sudo because mix does a lot of stuff that should not ever be run as root, Ever.
As I said earlier: I can compile. I can even deploy manually without gatling. But the gatling mix commands do not work. If you want to continue to criticize gatling, please do it in their repo so that they can discuss this with you. This is definitely the wrong place for that.
Not just criticizing the design, I’m thinking it could be the cause of your error (it is the same reason why you should never ever eversudo make install a C/C++ project and instead should do make && sudo make install). What are all of the commands being run on the remote server right before the gatling command? Is it ‘just’ the gatling command, because if so then mix is compiling as root and configing as root and doing everything as root which is really really really bad to do, but it should not be ‘just’ the gatling command as deps also have to be fetched and all, so what are all of the commands being done?