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

Question

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

Answer 1

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.