Ansible-Befehlsaufgabe läuft in "Exec format error"

10052
SadBunny

Ich habe diese ansehnliche Aufgabe geschrieben, um einen Prozess auf einer Remote-Vagrant-Box auszuführen. (Nun, eigentlich ist die ansible-Datei selbst viel länger, aber dies ist ein Reproduktionsprogramm, das nur das Startskript ausführt .)

--- - 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 }}"

Es funktioniert mit diesen vars in der enthaltenen vars-Datei:

--- 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"

Die Idee ist, den Benutzer "myappname" auf der Remote-Box zu verwenden (Aliasnamen korrekt durch "myappname_server", andere Spiele, gegen die ich ausgeführt werde, funktionieren einwandfrei), um "/ home / myappname / bin / run" auszuführen, nachdem das Verzeichnis in "/" geändert wurde. home / myappname / bin ". Wenn ich das manuell mache, funktioniert alles gut, dh die Verzeichnisse sind vorhanden, die Dateien sind lesbar, das Skript funktioniert usw., alles großartig. Wenn ich jedoch das Skript ausführte, scheint etwas mit der Generierung des ausführbaren Ausführungscodes in Frage zu stehen. Habe ich es und meine config so)? Ist es ansible?

Ich habe es mit -vvvv gestartet, um viele Informationen zu erhalten:

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

Ich habe Dinge ausprobiert wie:

  • mit Schrägstrichen nach dem Verzeichnis herumspielen
  • Verwendung mit relativen und absoluten Pfaden auf dem Remote-Computer
  • arbeite mit und ohne sudo und sudo_user in meinen Aufgaben

Ich weiß, dass alle anderen Ansible-Module, die ich mit den gleichen Vars aus einigen benachbarten Spielbüchern verwende, einwandfrei funktionieren. Auch integrierte Elemente wie Gruppe, Benutzer, Datei, apt, nicht archiviert, kopieren. Beachten Sie, dass einige der Gruppen- und Benutzermaterialien auch korrekt sind, daher weiß ich, dass auch alles in Ordnung ist.

/ edit: Ich weiß auch, dass der Pfad zum Laufskript korrekt ist. Wenn ich das Laufskript umbenenne und das Abspielbuch starte, erhalte ich einen anderen Fehler ("msg: [Errno 2] Keine solche Datei oder Verzeichnis", wie erwartet). . Es wird also versucht, das vorhandene Ausführungsskript auszuführen, schlägt jedoch fehl.

Aber nichts scheint zu funktionieren. Was ist los, was ist mit dem letzten erzeugten EXEC-Zeug los? Vielen Dank für Ihre Zeit.

4

3 Antworten auf die Frage

6
thenickdude

Wenn Sie versuchen, ein Shell-Skript auszuführen, überprüfen Sie Folgendes:

  • Dass es keine Shebang-Linie an der Spitze fehlt, wie:

    #!/usr/bin/env bash
  • Dass der Benutzer ansible ausführen wird, für den er Ausführungsberechtigungen hat (zB Modus 0755)
0
grawity

"Formatfehler ausführen" bedeutet einfach, dass Sie versucht haben, eine Datei auszuführen, die der Kernel nicht als gültiges Programm erkennt - sie ist in einem ungeeigneten Format. In diesem Fall scheint das rmauf dem Zielserver zuzutreffen.

Ssh direkt in den Server und überprüfen, ob das rmfunktioniert; Verwenden Sie file $(which rm)diese Option, um das Format zu überprüfen (vergleichen Sie es mit anderen Tools wie mkdir). Machen Sie dasselbe mit /usr/bin/pythonnur für alle Fälle. Vielleicht wurde es von einem anderen Architektursystem oder von einem anderen Betriebssystem kopiert oder völlig mit Müll gefüllt.

Vielen Dank! Denke aber nicht so: '(rm funktioniert einwandfrei (funktioniert auch auf der Zielbox, auch mit der Option -rf). Die Zielbox ist ein Standard-Setup von Ubuntu 14.04 Vagrant. Ich habe die Ausgabe von überprüft andere Playbooks und sie können ihre temporären Dateien problemlos verwenden, so dass dies nicht der Fall sein kann, und der Fehler scheint für mich auf eine ungültige generierte "EXEC" -Struktur zu stoßen. Der Parser hat vergessen, ein spezielles Zeichen zu entgehen oder so. Der zweite im Dreierblock hat ein komisches "u '/ bin / sh" in der Zeile, sieht seltsam aus ... Letztes, bevor die Tempfiles entfernt werden. Wie kam es dahin? SadBunny vor 9 Jahren 0
@SadBunny: Tut es? Programme verwenden 'errno' nicht für höhere Fehler; Es kommt fast immer aus einfachen libc-Funktionen. Zu diesem Zeitpunkt ist die einzige verbleibende Struktur ein einfaches C-Array, das execvp () übergeben wird. die einzigen Fehler kommen vom Kernel; und ENOEXEC "Exec format error" hat eine ziemlich spezifische Bedeutung. Ich würde sagen, es ist nur ein Zufall, dass Ansibles Log-Nachrichten auch "EXEC" sagen (da sie ja über die Ausführung eines Befehls sprechen). grawity vor 9 Jahren 0
ok, das ist ein bisschen über meinem Gehaltsniveau, sozusagen :) Ich versuche nur, ein Laien-Sherlocking in dieser Hinsicht zu machen ... Danke für die Erklärung. Anscheinend ist es jedoch kein defektes "rm", da andere Playbooks von / auf dieselben Systeme unter denselben Benutzern ausgeführt werden. In Anbetracht Ihrer Einsichten und der "Beweise" stimmt möglicherweise etwas mit dem eigentlichen Run-Skript oder der Shell, die es ausführt, oder etwas ... Ich werde morgen bei der Arbeit darauf zurückkommen. Danke fürs Nachdenken! SadBunny vor 9 Jahren 0
Übrigens ergibt die Datei $ (die rm) Folgendes: vagrant @ vagrant-ubuntu-trusty-64: ~ $ -Datei $ (die rm) / bin / rm: ELF-ausführbare 64-Bit-LSB-Datei, x86-64, Version 1 ( SYSV), dynamisch verknüpft (verwendet Shared Libs), für GNU / Linux 2.6.24 BuildID [sha1] = da0387e892c7a6dc57acf6618891cdb97f7f605c, gestrippt SadBunny vor 9 Jahren 0
0
jayunit100

Im Allgemeinen kann "exec format error" in ansible Folgendes bedeuten:

  • Ein Programm, das Sie ausführen können, ist buchstäblich keine ausführbare Datei.
  • ansible hat eine als ausführbare Datei markierte Datei gefunden, die nicht wirklich ausführbar ist, und hat versucht, sie auszuführen.

Mit anderen Worten: Dies bedeutet fast immer, dass Berechtigungen nicht korrekt sind, sie können jedoch in beide Richtungen auftreten (unterprivilegierte oder überprivilegierte Dateien können Ausführungsfehler auf unterschiedliche Weise verursachen).

Persönlich habe ich festgestellt, dass ich einen solchen Fehler bekomme, wenn ich in bestimmten Verzeichnissen "chmod 777 / etc / ansible / facts / .." mache und so weiter.

Verwandte Probleme