7

I have a Meteor application I'm deploying on EC2 instances using CodeDeploy (local build -> S3 -> CodeDeploy -> EC2).

I'm running into an issue I didn't have a week ago: when creating a deployment, it fails at the ApplicationStop step with the message

[stderr]bash: /opt/codedeploy-agent/deployment-root/.../scripts/stop.sh: /bin/sh^M: bad interpreter: No such file or directory

I'm aware that this should be an issue of Windows style line endings, but it looks like it's not

~$ md5sum stop.sh
d41d8cd98f00b204e9800998ecf8427e stop.sh
~$ dos2unix stop.sh
~$ md5sum stop.sh
d41d8cd98f00b204e9800998ecf8427e stop.sh

If I open the file in an hexadecimal editor, the line ending looks like 0x0a, and not 0x0d0a (Windows style).


    00000000: 2321 2f62 696e 2f73 680a 736f 7572 6365  #!/bin/sh.source
    00000010: 202f 686f 6d65 2f65 6332 2d75 7365 722f   /home/ec2-user/
    ...

Just to be sure, I downloaded the deployment archive from S3, extracted it and checked again - the line endings are indeed as described above.

This is quite strange since I did not have the problem about a week ago, and if I try to deploy version that was successfully deployed a week ago, the same issue occurs (!!)... even if it was working at the time.

Help appreciated!

[Update] : removing the first line from my stop.sh script, /bin/sh, doesn't change anything. I guess sudo ln -s /bin/sh /bin/sh^M should work for a dirty quick fix, but I'd like a cleaner solution. :/

[Update 2] : I've identified that for some reason, CodeDeploy is using the wrong deployment archive on the instances. Screenshot If I go to /opt/codedeploy-agent/.../d-GBQV1EHSE, this is indeed an old deployment with an issue of Windows style line returns... but CodeDeploy shouldn't use this archive /opt/codedeploy-agent/.../d-XWEJW9SVE exists and contains a valid archive.

Thanks

christophetd
  • 3,834
  • 20
  • 33

2 Answers2

9

After discussing a bit with christophetd, we found that there was a problem in the configuration which pointed to another (old) stop.sh, which indeed had a Windows-style CRLF.

Updating the configuration thus solved his problem.

Karl
  • 159
  • 6
  • 1
    I gave the bounty to this answer because the bounty was expiring. If anyone else has an explanation, please don't hesitate to post it! ;) – christophetd Apr 16 '16 at 09:21
  • This is an old post, but may be helpful - I think codedeploy will use the ApplicationStop of your last deployment (or maybe last successful deployment?) so you could get stuck in a loop where you had uploaded a version with a bad ApplicationStop that would never allow you to progress. To fix that, you can use a flag in the CLI that isn't available in the console called --ignore-application-stop-failures – David Ferretti Mar 30 '17 at 05:25
0

I got the solution of this issue. it's very simple.

When working with appspec.yml file our OS is linux but when we commit the code from our system using VSCODE in Windows all the files are in DOS format and we need to change it to unix format and need to push the code from GIT BASH not from VSCODE terminal which is again powershell or CMD.

  1. Track your all files inside local GIT repository folder in GIT BASH.
  2. Open the file using VI/VIM editor and hit keyboard button ESCAPE, type :set ff=unix and save the file using :wq!.

you can also see below article to convert file from DOS to Unix format.

https://www.studytonight.com/post/solved-getting-error-while-executing-a-sh-file-binbashm-bad-interpreter

  1. Commit and Push the code to your remote repo.

  2. Run deployment again and make sure to check your Codedeploy-Agent is running your system.

FaizanAhemad555
  • 1
  • 1
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Jul 16 '23 at 21:09