Ansible команда-задача сталкивается с "Ошибка формата Exec"

9880
SadBunny

Я написал это задание для запуска процесса на удаленном бродячем блоке. (На самом деле сам ANSIBLE файл намного длиннее, но это средство воспроизведения, которое запускает только стартовый скрипт.)

--- - hosts: myappname_server vars_files: - install_myappname_vars.yaml gather_facts: false sudo: true sudo_user: "{{ project_name }}"  tasks: - name: Restart application command: "{{ project_target_dir_env }}/run" args: chdir: "{{ project_target_dir_env }}" 

Он работает с этими переменными во включенном файле:

--- project_name: myappname project_source_dir_files: files/myappname project_source_dir_env: "{{ project_source_dir_files }}/environment_files" project_target_root: /home/myappname project_target_dir_env: "{{ project_target_root }}/bin" 

Идея состоит в том, чтобы использовать пользователя «myappname» в удаленном окне (с псевдонимом «myappname_server», другие игры, с которыми я работаю, работает нормально) для запуска «/ home / myappname / bin / run» после изменения каталога на «/ главная / myappname / бен». Если я делаю это вручную, все работает нормально, то есть каталоги существуют, файлы читаются, скрипт работает и т. Д., Все отлично. Но если я выполню сценарий, что-то не так с генерацией ANSIB-кода выполнения. Это я и мой конфиг на это надеемся)? Это ответственно?

Я запустил его с -vvvv, чтобы получить много информации:

monsterkill@monsterkill-ub-dt:~/playbooks$ ansible-playbook install_myappname_restart.yaml -vvvv  PLAY [myappname_server] **********************************************************   TASK: [Restart application] ***************************************************  <vagrant1> ESTABLISH CONNECTION FOR USER: vagrant <vagrant1> REMOTE_MODULE command chdir=/home/myappname/bin /home/myappname/bin/run <vagrant1> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/home/monsterkill/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'Port=22', '-o', 'IdentityFile=/home/monsterkill/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', 'vagrant1', "/bin/sh -c 'mkdir -p /tmp/ansible-tmp-1422343063.07-259463565013754 && chmod a+rx /tmp/ansible-tmp-1422343063.07-259463565013754 && echo /tmp/ansible-tmp-1422343063.07-259463565013754'"] <vagrant1> PUT /tmp/tmpBduhE7 TO /tmp/ansible-tmp-1422343063.07-259463565013754/command <vagrant1> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/home/monsterkill/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'Port=22', '-o', 'IdentityFile=/home/monsterkill/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', 'vagrant1', "/bin/sh -c 'chmod a+r /tmp/ansible-tmp-1422343063.07-259463565013754/command'"] <vagrant1> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/home/monsterkill/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'Port=22', '-o', 'IdentityFile=/home/monsterkill/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', 'vagrant1', u'/bin/sh -c \'sudo -k && sudo -H -S -p "[sudo via ansible, key=ucmsbsauynfzeeyxwdmgfduwovdneeqg] password: " -u myappname /bin/sh -c \'"\'"\'echo SUDO-SUCCESS-ucmsbsauynfzeeyxwdmgfduwovdneeqg; /usr/bin/python /tmp/ansible-tmp-1422343063.07-259463565013754/command\'"\'"\'\''] <vagrant1> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/home/monsterkill/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'Port=22', '-o', 'IdentityFile=/home/monsterkill/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', 'vagrant1', "/bin/sh -c 'rm -rf /tmp/ansible-tmp-1422343063.07-259463565013754/ >/dev/null 2>&1'"] failed: [vagrant1] => {"cmd": ["/home/myappname/bin/run"], "failed": true, "rc": 8} msg: [Errno 8] Exec format error  FATAL: all hosts have already failed -- aborting  PLAY RECAP ********************************************************************  to retry, use: --limit @/home/monsterkill/install_myappname_restart.yaml.retry  vagrant1 : ok=0 changed=0 unreachable=0 failed=1  

Я пробовал такие вещи, как:

  • играть с косой чертой после каталога
  • использование с относительными и абсолютными путями на удаленной машине
  • работать с и без sudo и sudo_user в моих задачах

Я знаю, что все другие ANSI-модули, которые я использую с той же кучей переменных из некоторых соседних сборников, работают нормально. Также встроенные вещи, такие как группа, пользователь, файл, apt, unarchive, copy. Обратите внимание, что некоторые из них также требуют правильной работы группы / пользователя, так что я знаю, что это тоже хорошо.

/ edit: Я также знаю, что путь к сценарию запуска указан правильно, потому что, если я переименую сценарий запуска и запусту книгу воспроизведения, я получу еще одну ошибку («msg: [Errno 2] Нет такого файла или каталога», как и ожидалось), Так что на самом деле он пытается запустить существующий скрипт запуска, но не удается.

Но ничего не работает. Что происходит, что не так с этим последним сгенерированным материалом EXEC? Спасибо за ваше время.

4

3 ответа на вопрос

6
thenickdude

Если вы пытаетесь запустить скрипт оболочки, проверьте:

  • То, что это не пропускает линию Шебанга наверху как:

    #!/usr/bin/env bash 
  • То, что пользователь ansible будет работать, поскольку имеет для него разрешения на выполнение (например, режим 0755)
0
grawity

«Ошибка формата exec» означает просто, что вы пытались выполнить файл, который ядро ​​не распознает как допустимую программу - он находится в неподходящем формате. В этом случае это относится к rmцелевому серверу.

Ssh прямо на сервер и убедитесь, что rmработает; используйте file $(which rm)для проверки его формата (сравните с другими инструментами, как mkdir). Сделайте то же самое на /usr/bin/pythonвсякий случай. Возможно, оно было скопировано из другой системы архитектуры, или из другой ОС, или полностью заполнено мусором.

Спасибо! Но не думайте так: '(rm работает нормально (отлично работает на целевой коробке, также с ключом -rf). Целевой коробкой является стандартная установка Ubuntu 14.04 Vagrant прямо из коробки. Я проверил вывод другие playbook-ы, и они могут просто нормально создавать свои временные файлы, так что этого не может быть. Кроме того, мне кажется, что ошибка указывает на то, что она обнаружила недопустимую сгенерированную структуру "EXEC". Например, парсер забыл экранировать специальный символ или что-то в этом роде. У второго в блоке из трех странных строк "u '/ bin / sh" в своей строке, выглядит странно ... Последнее, прежде чем удалять временные файлы. Как он туда попал? SadBunny 9 лет назад 0
@SadBunny: так ли это? Программы не используют «errno» для ошибок более высокого уровня; это почти всегда происходит из низкоуровневых функций libc. В этот момент единственной оставшейся структурой является простой массив C, предоставленный execvp (); единственные ошибки происходят из ядра; ENOEXEC «Ошибка формата Exec» имеет довольно специфическое значение. Я бы сказал, что это просто совпадение, что сообщения журнала Ansible также говорят «EXEC» (так как они говорят о выполнении команды). grawity 9 лет назад 0
хорошо, это немного выше моего paygrade, так сказать :) Я просто пытаюсь сделать Sherlocking какого-то непрофессионала в этом отношении ... Спасибо за объяснение. Тем не менее, очевидно, что это не сломанный «rm», так как другие playbooks выполнялись из одной системы в одну и ту же систему под теми же пользователями. Учитывая ваши идеи и «доказательства», может быть что-то не так с самим сценарием запуска или оболочкой, которая его выполняет, или с чем-то еще ... Я вернусь к этому завтра на работе. Спасибо, что подумали! SadBunny 9 лет назад 0
Кстати, файл $ (который rm) дает: vagrant @ vagrant-ubuntu-trusty-64: ~ $ file $ (which rm) / bin / rm: исполняемый 64-битный LSB ELF, x86-64, версия 1 ( SYSV), динамически связанный (использует общие библиотеки), для GNU / Linux 2.6.24, BuildID [sha1] = da0387e892c7a6dc57acf6618891cdb97f7f605c, раздетый SadBunny 9 лет назад 0
0
jayunit100

В общем, «ошибка формата exec» в ansible может означать:

  • программа, которую вы дали выполнить, буквально не является исполняемой.
  • ansible нашел файл, помеченный как исполняемый файл, который на самом деле не является исполняемым, и попытался выполнить его.

Другими словами: это почти всегда означает, что права доступа являются неверными, но это может происходить в обоих направлениях (файлы с недостаточным или избыточным доступом могут по-разному вызывать ошибки exec).

Лично я обнаружил, что я получаю такую ​​ошибку, когда я делаю что-то вроде "chmod 777 / etc / ansible / fact / .." в определенных каталогах и так далее.

Похожие вопросы