CODEWITHSUNDEEP
amazon-web-servicesamazon-ec2line-endingsaws-code-deploy
christophetd
christophetd

Reputation: 3874

CodeDeploy deployment fails: bad interpreter /bin/sh^M

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

Upvotes: 7

Views: 2020

Answers (2)

FaizanAhemad555
FaizanAhemad555

Reputation: 1

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.

Upvotes: 0

Karl
Karl

Reputation: 159

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.

Upvotes: 9

Related Questions