Return code is not 0 как исправить

Stuck with Non-Zero return code: Ansible error? We can help you.

Ansible will fail if the exit status of a task is any non-zero value.

As part of our Server Management Services, we assist our customers with several Ansible queries.

Today, let us see how we can fix this error.

Non-Zero return code: Ansible

Generally, the error looks like this:

TASK [Non-Zero return] 
**********************************************************************************
fatal: [server1.lab.com]: FAILED! => {“changed”: true, “cmd”: “ls | grep wp-config.php”, “delta”: “0:00:00.021103”, “end”: “2021-06-29 12:53:49.222176”, “msg”: “non-zero return code”, “rc”: 1, “start”: “2021-06-29 12:53:49.201073”, “stderr”: “”, “stderr_lines”: [], “stdout”: “”, “stdout_lines”: []}
fatal: [server2.lab.com]: FAILED! => {“changed”: true, “cmd”: “ls | grep wp-config.php”, “delta”: “0:00:00.021412”, “end”: “2021-06-29 12:53:50.697567”, “msg”: “non-zero return code”, “rc”: 1, “start”: “2021-06-29 12:53:50.676155”, “stderr”: “”, “stderr_lines”: [], “stdout”: “”, “stdout_lines”: []}
fatal: [server3.lab.com]: FAILED! => {“changed”: true, “cmd”: “ls | grep wp-config.php”, “delta”: “0:00:00.015554”, “end”: “2021-06-29 12:53:50.075555”, “msg”: “non-zero return code”, “rc”: 1, “start”: “2021-06-29 12:53:50.060001”, “stderr”: “”, “stderr_lines”: [], “stdout”: “”, “stdout_lines”: []}

In common, if a command exits with a zero exit status it means it has run successfully.

On the other hand, any non-zero exit status of the command indicates an error.

For example,

$ date
Tuesday 29 June 2021 05:21:28 PM IST
$ echo $?
0

Here, we can see the successful execution of the shell command “date”. Hence, the exit status of the command is 0.

A non-zero exit status indicates failure. For example,

$ date yesterday
date: invalid date ‘yesterday’
$ echo $?
1

Here, the argument for the ‘date’ command, “yesterday”, is invalid. Hence, the exit status is 1, indicating the command ended in error.

However, though we execute properly, there are some commands which return a non-zero value.

$ ls | grep wp-config.php
$ echo $?
1

Here, the wp-config.php file doesn’t exist in that directory. Even though the command executes without error, the exit status is 1.

By default, Ansible will report it as failed.

How to resolve the problem?

The best practice in order to solve this is to avoid the usage of shell command in the playbook.

Instead of the shell command, there is a high chance for an ansible module that does the same operation.

So, we can use the ansible built-in module find which allows locating files easily through ansible.

Alternatively, we can define the condition for a failure at the task level with the help of failed_when.

For example,

—
– hosts: all
tasks:
– name: Non-Zero return
shell: “ls | grep wp-config.php”
register: wp
failed_when: “wp.rc not in [ 0, 1 ]”

TASK [Non-Zero return]
***********************************************************************************************************
changed: [server1.lab.com]
changed: [server2.lab.com]
changed: [server3.lab.com]

Though the exit status is not Zero, the task continues to execute on the server.

Here, the exit status registers to a variable and then pass through the condition. If the return value doesn’t match the condition, only then the task will report as a failure.

On the other hand, we can ignore the errors altogether.

For that, we use ignore_errors in the task to ignore any failure during the task.

—
– hosts: all
tasks:
– name: Non-Zero return
shell: “ls | grep wp-config.php”
ignore_errors: true

ASK [Non-Zero return]
***********************************************************************************************************
fatal: [server1.lab.com]: FAILED! => {“changed”: true, “cmd”: “ls | grep wp-config.php”, “delta”: “0:00:00.004055”, “end”: “2021-06-29 13:09:20.631570”, “msg”: “non-zero return code”, “rc”: 1, “start”: “2021-06-29 13:09:20.627515”, “stderr”: “”, “stderr_lines”: [], “stdout”: “”, “stdout_lines”: []}
…ignoring
fatal: [server2.lab.com]: FAILED! => {“changed”: true, “cmd”: “ls | grep wp-config.php”, “delta”: “0:00:00.006745”, “end”: “2021-06-29 13:09:22.110059”, “msg”: “non-zero return code”, “rc”: 1, “start”: “2021-06-29 13:09:22.103314”, “stderr”: “”, “stderr_lines”: [], “stdout”: “”, “stdout_lines”: []}
…ignoring
fatal: [server3.lab.com]: FAILED! => {“changed”: true, “cmd”: “ls | grep wp-config.php”, “delta”: “0:00:00.004957”, “end”: “2021-06-29 13:09:21.465326”, “msg”: “non-zero return code”, “rc”: 1, “start”: “2021-06-29 13:09:21.460369”, “stderr”: “”, “stderr_lines”: [], “stdout”: “”, “stdout_lines”: []}
…ignoring

By default, for ansible to recognize the task complition, the exit status must be Zero. Otherwise, it will fail.

We can manipulate the exit status of the task by registering the return value to a variable and then use conditional to determine if the task fails or succeeds.

To continue the playbook, in spite of the failure, we can use the ignore_errors option on the task.

[Confused with the procedure? We are here for you]

Conclusion

In short, we saw how our Support Techs fix the Ansible error for our customers.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

Обработка ошибок в плейбуках

Когда Ansible получает ненулевой код возврата от команды или сбоя от модуля,по умолчанию он прекращает выполнение на этом хосте и продолжается на других хостах.Тем не менее,в некоторых случаях вам может потребоваться иное поведение.Иногда ненулевой код возврата указывает на успех.Иногда вы хотите,чтобы сбой на одном хосте остановил выполнение на всех хостах.Ansible предоставляет инструменты и настройки,чтобы справиться с этими ситуациями и помочь вам получить поведение,вывод и отчетность вы хотите.

• Игнорирование неудачных команд
• игнорирование недоступных ошибок хоста
• Сброс недоступных хостов
• Дескрипторы и отказ
• Defining failure
• Defining “changed”
• Обеспечение успеха для командования и снаряда

• Прерывание игры на всех хозяевах

  • Прерывание первой ошибки:any_errors_fatal
  • Установка максимального процента отказа
• Ошибки управления блоками

Игнорирование неудачных команд

По умолчанию Ansible прекращает выполнение задач на хосте при сбое задачи на этом хосте. Вы можете использовать ignore_errors , чтобы продолжить несмотря на сбой:

- name: Do not count this as a failure
  ansible.builtin.command: /bin/false
  ignore_errors: yes

Директива ignore_errors работает только тогда, когда задача может быть запущена и возвращает значение «сбой». Это не заставляет Ansible игнорировать ошибки неопределенных переменных, сбои соединения, проблемы с выполнением (например, отсутствующие пакеты) или синтаксические ошибки.

игнорирование недоступных ошибок хоста

Новинка в версии 2.7.

Вы можете игнорировать сбой задачи из-за того, что экземпляр хоста недоступен с ключевым словом ignore_unreachable . Ansible игнорирует ошибки задачи, но продолжает выполнять будущие задачи на недостижимом хосте. Например, на уровне задачи:

- name: This executes, fails, and the failure is ignored
  ansible.builtin.command: /bin/true
  ignore_unreachable: yes

- name: This executes, fails, and ends the play for this host
  ansible.builtin.command: /bin/true

И на игровом уровне:

- hosts: all
  ignore_unreachable: yes
  tasks:
  - name: This executes, fails, and the failure is ignored
    ansible.builtin.command: /bin/true

  - name: This executes, fails, and ends the play for this host
    ansible.builtin.command: /bin/true
    ignore_unreachable: no

Сброс недоступных хостов

Если Ansible не может подключиться к хосту, он помечает этот хост как «НЕДОСТУПНЫЙ» и удаляет его из списка активных хостов для выполнения. Вы можете использовать meta: clear_host_errors для повторной активации всех хостов, чтобы последующие задачи могли снова попытаться связаться с ними.

Дескрипторы и отказ

Ansible runs handlers at the end of each play. If a task notifies a handler but another task fails later in the play, by default the handler does not run on that host, which may leave the host in an unexpected state. For example, a task could update a configuration file and notify a handler to restart some service. If a task later in the same play fails, the configuration file might be changed but the service will not be restarted.

Вы можете изменить это поведение с --force-handlers опций командной строки, в том числе путем force_handlers: True в пьесе, или путем добавления force_handlers = True в ansible.cfg. Когда обработчики принудительно запущены, Ansible будет запускать все обработчики уведомлений на всех хостах, даже на хостах с неудачными задачами. (Обратите внимание, что некоторые ошибки все еще могут помешать запуску обработчика, например, когда хост становится недоступным.)

Defining failure

Ansible позволяет определить, что означает «сбой» в каждой задаче, используя условие failed_when . Как и все условные операторы в Ansible, списки нескольких условий failed_when объединяются неявным оператором and , что означает, что задача завершается сбоем только при соблюдении всех условий. Если вы хотите инициировать сбой при выполнении любого из условий, вы должны определить условия в строке с явным оператором or .

Проверить на неудачу можно с помощью поиска слова или фразы в выводе команды:

- name: Fail task when the command error output prints FAILED
  ansible.builtin.command: /usr/bin/example-command -x -y -z
  register: command_result
  failed_when: "'FAILED' in command_result.stderr"

или на основании кода возврата:

- name: Fail task when both files are identical
  ansible.builtin.raw: diff foo/file1 bar/file2
  register: diff_cmd
  failed_when: diff_cmd.rc == 0 or diff_cmd.rc >= 2

Вы также можете комбинировать несколько условий для отказа.Эта задача будет неудачной,если оба условия верны:

- name: Check if a file exists in temp and fail task if it does
  ansible.builtin.command: ls /tmp/this_should_not_be_here
  register: result
  failed_when:
    - result.rc == 0
    - '"No such" not in result.stdout'

Если вы хотите, чтобы задача не выполнялась при выполнении только одного условия, измените определение failed_when на:

failed_when: result.rc == 0 or "No such" not in result.stdout

Если у вас слишком много условий для аккуратного размещения в одной строке, вы можете разделить его на многострочное значение yaml с помощью > :

- name: example of many failed_when conditions with OR
  ansible.builtin.shell: "./myBinary"
  register: ret
  failed_when: >
    ("No such file or directory" in ret.stdout) or
    (ret.stderr != '') or
    (ret.rc == 10)

Defining “changed”

Ansible позволяет вам определить, когда конкретная задача «изменила» удаленный узел, используя условное changed_when . Это позволяет вам определить, на основе кодов возврата или вывода, следует ли сообщать об изменении в статистике Ansible и должен ли запускаться обработчик или нет. Как и все условные операторы в Ansible, списки нескольких условий changed_when объединяются неявным оператором and , что означает, что задача сообщает об изменении только тогда, когда все условия соблюдены. Если вы хотите сообщить об изменении при выполнении любого из условий, вы должны определить условия в строке с явным оператором or .Например:

tasks:

  - name: Report 'changed' when the return code is not equal to 2
    ansible.builtin.shell: /usr/bin/billybass --mode="take me to the river"
    register: bass_result
    changed_when: "bass_result.rc != 2"

  - name: This will never report 'changed' status
    ansible.builtin.shell: wall 'beep'
    changed_when: False

Вы также можете объединить несколько условий,чтобы отменить результат «изменено»:

- name: Combine multiple conditions to override 'changed' result
  ansible.builtin.command: /bin/fake_command
  register: result
  ignore_errors: True
  changed_when:
    - '"ERROR" in result.stderr'
    - result.rc == 2

Дополнительные примеры условного синтаксиса см. В разделе Определение ошибки .

Обеспечение успеха для командования и снаряда

В командных и оболочки модулей заботятся о кодах возврата, поэтому если у вас есть команда , чей успешный код завершения не равен нулю, то вы можете сделать это:

tasks:
  - name: Run this command and ignore the result
    ansible.builtin.shell: /usr/bin/somecommand || /bin/true

Прерывание игры на всех хозяевах

Иногда требуется, чтобы сбой на одном хосте или сбой на определенном проценте хостов прервали всю игру на всех хостах. Вы можете остановить выполнение воспроизведения после первого сбоя с помощью any_errors_fatal . Для более max_fail_percentage управления вы можете использовать max_fail_percentage, чтобы прервать выполнение после сбоя определенного процента хостов.

Прерывание первой ошибки:any_errors_fatal

Если вы устанавливаете any_errors_fatal и задача возвращает ошибку, Ansible завершает фатальную задачу на всех хостах в текущем пакете, а затем прекращает воспроизведение на всех хостах. Последующие задания и спектакли не выполняются. Вы можете избавиться от фатальных ошибок, добавив в блок раздел восстановления. Вы можете установить any_errors_fatal на уровне игры или блока:

- hosts: somehosts
  any_errors_fatal: true
  roles:
    - myrole

- hosts: somehosts
  tasks:
    - block:
        - include_tasks: mytasks.yml
      any_errors_fatal: true

Вы можете использовать эту функцию,когда все задачи должны быть на 100% успешными,чтобы продолжить выполнение Playbook.Например,если вы запускаете сервис на машинах в нескольких центрах обработки данных с балансировщиками нагрузки для передачи трафика от пользователей к сервису,вы хотите,чтобы все балансировщики нагрузки были отключены до того,как вы остановите сервис на техническое обслуживание.Чтобы гарантировать,что любой сбой в задаче,отключающей работу балансировщиков нагрузки,остановит все остальные задачи:

---
- hosts: load_balancers_dc_a
  any_errors_fatal: true

  tasks:
    - name: Shut down datacenter 'A'
      ansible.builtin.command: /usr/bin/disable-dc

- hosts: frontends_dc_a

  tasks:
    - name: Stop service
      ansible.builtin.command: /usr/bin/stop-software

    - name: Update software
      ansible.builtin.command: /usr/bin/upgrade-software

- hosts: load_balancers_dc_a

  tasks:
    - name: Start datacenter 'A'
      ansible.builtin.command: /usr/bin/enable-dc

В данном примере Ansible запускает обновление программного обеспечения на передних концах только в том случае,если все балансировщики нагрузки успешно отключены.

Установка максимального процента отказа

По умолчанию,Ansible продолжает выполнять задачи до тех пор,пока есть хосты,которые еще не вышли из строя.В некоторых ситуациях,например,при выполнении скользящего обновления,вы можете прервать воспроизведение,когда достигнут определенный порог неудач.Для этого вы можете установить максимальный процент сбоев при воспроизведении:

---
- hosts: webservers
  max_fail_percentage: 30
  serial: 10

Параметр max_fail_percentage применяется к каждому пакету, когда вы используете его с последовательным интерфейсом . В приведенном выше примере, если более 3 из 10 серверов в первой (или любой) группе серверов вышли из строя, остальная часть игры будет прервана.

Ошибки управления блоками

Вы также можете использовать блоки для определения ответов на ошибки задачи. Этот подход похож на обработку исключений во многих языках программирования. См. Подробности и примеры в разделе Обработка ошибок с помощью блоков .

Ansible

• Контроль над тем,где выполняются задачи:делегирование и местные действия.

  По умолчанию Ansible собирает факты и выполняет все задачи на машинах, которые соответствуют строке hosts из вашего playbook.

• Настройка удаленной среды

  Новое в версии 1.1.

• Использование фильтров для манипулирования данными

  Фильтры позволяют преобразовывать данные JSON в разделенный URL-адрес YAML, извлекать имя хоста, получать хэш строки SHA1, добавлять несколько целых чисел и многое другое.

• Объединение и выбор данных

  Вы можете комбинировать данные из нескольких источников и типов, выбирать значения больших структур, предоставляя точный контроль над комплексом Новое в версии 2.3.

By default Ansible stops executing tasks on a host when a task fails on that host. You can use ignore_errors to continue on in spite of the failure:

If Ansible cannot connect to a host, it marks that host as ‘UNREACHABLE’ and removes it from the list of active hosts for the run. You can use meta: clear_host_errors to reactivate all hosts, so subsequent tasks can try to reach them again.

Ansible runs handlers at the end of each play. If a task notifies a handler but another task fails later in the play, by default the handler does not run on that host, which may leave the host in an unexpected state. For example, a task could update a configuration file and notify a handler to restart some service. If a task later in the same play fails, the configuration file might be changed but the service will not be restarted.
You can change this behavior with the —force-handlers command-line option, by including force_handlers: True in a play, or by adding force_handlers = True to ansible.cfg. When handlers are forced, Ansible will run all notified handlers on all hosts, even hosts with failed tasks. (Note that certain errors could still prevent the handler from running, such as a host becoming unreachable.)

Ansible lets you define what “failure” means in each task using the failed_when conditional. As with all conditionals in Ansible, lists of multiple failed_when conditions are joined with an implicit and, meaning the task only fails when all conditions are met. If you want to trigger a failure when any of the conditions is met, you must define the conditions in a string with an explicit or operator.

Ansible lets you define when a particular task has “changed” a remote node using the changed_when conditional. This lets you determine, based on return codes or output, whether a change should be reported in Ansible statistics and whether a handler should be triggered or not. As with all conditionals in Ansible, lists of multiple changed_when conditions are joined with an implicit and, meaning the task only reports a change when all conditions are met. If you want to report a change when any of the conditions is met, you must define the conditions in a string with an explicit or operator. For example:

The command and shell modules care about return codes, so if you have a command whose successful exit code is not zero, you can do this:

Aborting a play on all hosts

Sometimes you want a failure on a single host, or failures on a certain percentage of hosts, to abort the entire play on all hosts. You can stop play execution after the first failure happens with any_errors_fatal. For finer-grained control, you can use max_fail_percentage to abort the run after a given percentage of hosts has failed.

If you set any_errors_fatal and a task returns an error, Ansible finishes the fatal task on all hosts in the current batch, then stops executing the play on all hosts. Subsequent tasks and plays are not executed. You can recover from fatal errors by adding a rescue section to the block. You can set any_errors_fatal at the play or block level:

By default, Ansible continues to execute tasks as long as there are hosts that have not yet failed. In some situations, such as when executing a rolling update, you may want to abort the play when a certain threshold of failures has been reached. To achieve this, you can set a maximum failure percentage on a play:

Controlling errors in blocks

The main issue in your code is that $? is expanded before ssh is called. This is due to quoting. All expansions in a double-quoted string are expanded before the string is used. In addition to that, the double-quoted string that you are using with ssh contains other double-quoted sections. These sections would be unquoted, just like the substring abc is unquoted in "123"abc"456".

Instead of trying to execute a complicated command on the remote host, just let the ssh command cat the passwd file, then grep that:

if ssh -n "sandeep@$ipaddress" cat /etc/passwd | grep -q -F -e "$userid"
then
    echo "User exists"
else
    echo "User does not exist"
fi >>"/tmp/userfind_$DATE.txt"

Also, consider reading from the user and server list using a while loop instead:

while IFS= read -r userid; do
   # ...
done </home/sandeep/Project_finduser01/userslist

You may also redirect the outermost loop to your output file instead of redirecting every single echo:

while ...; do
    while ...; do
       # stuff
    done <userlist
done <serverlist  >"/tmp/userfind_$DATE.txt"

If your user list is long, you may want to only get the passwd from the remote host once, and then query that several times

while ...; do
    scp "sandeep@$ipaddress:/etc/passwd" passwd.tmp
    while ...; do
       if grep -q -F -e "$userid" passwd.tmp; then
          # exists
       fi
    done <userlist
done <serverlist  >"/tmp/userfind_$DATE.txt"

Even more efficiently would be to read the user list into an awk array and then match the usernames from the passwd file against them. That would get rid of the innermost loop entirely.

The username is found in a particular field in the passwd file. With your approach, you would match both marc and marco if you searched for marc. To match a bit more carefully, consider using a pattern such as "^$userid:" instead of matching against the whole line (and drop the -F that I introduced above if you’re still using grep to do this).

You may also avoid the parsing of the passwd file completely with

getent passwd "$userid" >/dev/null

This returns a zero exit code (success) if the user exists and non-zero otherwise.

I.e.,

if ssh -n "sandeep@$ipaddress" getent passwd "$userid" >/dev/null
then
    # exists
else
    # does not exist
fi

This would do one ssh call against the remote host per user though. This could be made a bit more efficient by not closing the connection between each call (the below would keep the connection open for one minute):

if ssh -n -o ControlMaster=auto -o ControlPersist=1m "sandeep@$ipaddress" getent passwd "$userid" >/dev/null
then
    # exists
else
    # does not exist
fi