Ошибка развертывания CodeDeploy: неверный интерпретатор / bin / sh ^ M

У меня есть приложение Meteor, которое я развертываю на экземплярах EC2 с помощью CodeDeploy (локальная сборка -> S3 -> CodeDeploy -> EC2).

У меня проблема, которой не было неделю назад: при создании развертывания происходит сбой на этапе ApplicationStop с сообщением

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

Я знаю, что это должно быть проблемой окончаний строк в стиле Windows, но похоже, что это не так.

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

Если я открою файл в шестнадцатеричном редакторе, окончание строки будет иметь вид 0x0a, а не 0x0d0a (стиль Windows).


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

На всякий случай я загрузил архив развертывания с S3, извлек его и снова проверил - окончания строк действительно такие, как описано выше.

Это довольно странно, так как около недели назад у меня не было проблемы, и если я попытаюсь развернуть версию, которая была успешно развернута неделю назад, возникает такая же проблема (!!) ... даже если она работала в то время .

Помощь приветствуется!

[Обновление]: удаление первой строки из моего скрипта stop.sh, /bin/sh, ничего не меняет. Я полагаю, что sudo ln -s /bin/sh /bin/sh^M должно работать для грязного быстрого исправления, но я хотел бы более чистое решение. : /

[Обновление 2]: я обнаружил, что по какой-то причине CodeDeploy использует неправильный архив развертывания на экземплярах. Снимок экрана Если я перейду к /opt/codedeploy-agent/.../d-GBQV1EHSE, это действительно старое развертывание с проблемой возврата строки в стиле Windows ... но CodeDeploy не должен использовать этот архив /opt/codedeploy-agent/.../d-XWEJW9SVE существует и содержит действительный архив.

Спасибо


person christophetd    schedule 07.04.2016    source источник


Ответы (1)


Поговорив немного с christophetd, мы обнаружили, что в конфигурации есть проблема, указывающая на другой (старый) файл stop.sh, который действительно имел CRLF в стиле Windows.

Таким образом, обновление конфигурации решило его проблему.

person Karl    schedule 12.04.2016
comment
Я назначил награду за этот ответ, потому что срок ее действия истек. Если у кого-то еще есть объяснение, пожалуйста, не стесняйтесь публиковать его! ;) - person christophetd; 16.04.2016
comment
Это старый пост, но он может быть полезен - я думаю, что codedeploy будет использовать ApplicationStop вашего последнего развертывания (или, может быть, последнего успешного развертывания?), Поэтому вы можете застрять в цикле, когда вы загрузили версию с плохим ApplicationStop, который никогда не позволяй тебе прогрессировать. Чтобы исправить это, вы можете использовать флаг в интерфейсе командной строки, который недоступен в консоли, под названием --ignore-application-stop-failures. - person David Ferretti; 30.03.2017