Following services are not running: application-locust-follower-1

[leonidumanskiy]

Hi, I followed the guide and I got this error in my EB Dashboard:

Following services are not running: application-locust-follower-1

When I open the locust dashboard, it says the number of slaves is 0. It looks like a slave process is failing to start, but I can't find anything in logs.
If I manually start it by connecting to my instance and running /bin/bash -c "exec /usr/local/bin/locust -f locustfile.py --port=9876 --slave --master-host=$(<.masterIP)", it works, but this is not a viable solution.

[leonidumanskiy]

So it looks like the build.rb file failed to run, and there is no masterIP file in the application folder. Because of that, follower process fails to start.
However, I still can't figure out why ruby script fails to run.

[leonidumanskiy]

It seems that ruby failed to run build.rb. After I changed Buildfile to:
build: gem install aws-sdk && ruby ./build.rb

The problem is solved. However, I still struggle with running multiple slaves.

[abhiksingh]

@leonidumanskiy you shouldn't need to add the gem install. The app should work without it. Could you please try the latest commit and let me know if you continue to run into issues?

[szitar]

The issue still exists on the latest commit.

[bobodell]

The issue appears to manifest itself when running eb deploy from a Windows 10 OS. On Windows 10 if you change the buildfile to

build: ruby ./build.rb

The problem no longer exists. This doesn't seem to occur when running eb deploy from another OS.

[rahulrajaram]

As @bobodell points out, the issue stems from a disparity across file systems related to the executable-ness of files, although there's not enough information to tell whether the subsequent analysis relates completely to OP's experience.

Specifically in this case, the source of the problem is that Windows filesystems ignore the executable-ness of build.rb, so when the EBCLI packages (and when the Beanstalk instance unpackages) the application source code, the executable nature of build.rb is lost. So, the Beanstalk instance is unable to deem build.rb executable, and hence fails to execute it on the cloud.

Solutions:

1. core.filemode: The developers of git recognized this problem. The solution provided to users accessing repositories on file systems different from the ones the repositories were originally created in is the core.filemode git config. Setting this config to false effectively tells git to preserve the executable bit by asking it to not trust the file system's inference of the file's executable-ness. In addition to setting the config to false, you might also need to run git update-index --chmod=+x build.rb for build.rb to actually be deemed executable. To summarize:

   • git config core.filemode false
   • git update-index --chmod=+x build.rb
   • git commit -m "tell git to preserve executable bits"
   • eb create ...

   I have been able to verify through the EBCLI on Windows:

   • with core.filemode unset/set to true, the deployment fails
   • the deployment subsequently succeeds when the config is set to false (and I have followed the above steps).

   However, as this SO answer notes, you should be careful while setting this config to false -- only set it when you really need to.

2. Pass build.rb as an argument to ruby: as opposed to invoking the file as build.rb. This avoids relying on the executable-ness of the file and gives users unaware of this rather inconspicuous problem of lost bits a good first-time experience with the sample app. I propose we modify the corresponding invocation in Buildfile accordingly.

[bobflorian]

Thanks @rahulrajaram and @bobodell ; passing build.rb as an arugment to ruby does fix the problem on Windows. Definitely helped me out when I ran across this today, and nearly pulled my hair out!

[rahulrajaram]

@bobflorian , you're welcome!