Ansible: [Ошибка / Регрессия] При импорте mysql_db не удалось распаковать дамп

_From @ansibot 30 июля 2016 г., 16:32_

@Jmainguy ping, вопрос ждёт вашего ответа.
нажмите здесь, чтобы получить помощь по ботам

_From @Jmainguy 30 июля 2016 г., 20:10_

Я попытался воссоздать это на ansible-2.2.0-0.git201605131739.e083fa3.devel.el7.centos.noarch и не смог воспроизвести.

импортировал 240mb .tar.gz (заняло несколько часов, но это сработало).

Это было на centos, можете ли вы попробовать еще раз с devel на ubuntu и сообщить мне, происходит ли это все еще?

_From @ansibot 8 сентября 2016 г., 20:59_

@Jmainguy , пинг. Этот вопрос все еще ожидает вашего ответа.
нажмите здесь, чтобы получить помощь по ботам

_From @Jmainguy 9 сентября 2016 г. 18:19_

ansibot "needs_info"

_От @bmalynovytch 9 сентября 2016 г., 19: 3_

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

! needs_info

_From @ilyapoz 27 сентября 2016 г. 18:24_

Есть какие-то обходные пути? Все еще воспроизводимый на Ubuntu, надежный в виртуальном боксе
доступный 2.1.1.0

_From @ansibot 27 сентября 2016 г. 18:43_

@Jmainguy , пинг. Этот вопрос все еще ожидает вашего ответа.
нажмите здесь, чтобы получить помощь по ботам

_From @ilyapoz 27 сентября 2016 г. 18:44_

Извините, возможное обходное решение для небольших БД не сжимает дамп

_From @ansibot 9 декабря 2016 г., 19:50

Этот репозиторий заблокирован. Все новые проблемы и запросы на вытягивание следует размещать на странице https://github.com/ansible/ansible.

Пожалуйста, прочтите страницу repomerge в руководстве для разработчиков. Руководство содержит ссылки на инструменты, которые автоматически перемещают вашу задачу или запрос на перенос в репозиторий ansible / ansible.

_From @ulrith 20 декабря 2016 г., 11:35_

У меня такое же поведение с моим Ansible 2.2.0.0 на Ubuntu 16.04.
Забавно, но задача модуля «разархивировать» также не удается, если я попытаюсь распаковать архив перед загрузкой дампа в модуль mysql_db. >: - <
Очень плохо...

_From @sachavuk 4 января 2017 г., 17:38_

Привет,

У меня такая же проблема с Debian 7.8 с ansible 2.2.0.0 с тем же сообщением об ошибке: cry:

Добрый вечер,
Я надеюсь, что было правильно переместить проблему в это репо, как это предлагается в разделе « Перенести вопросы и PR в новое репо» .

Как @ulrith и @sachavuk, у меня тоже есть эта проблема. В моем случае проблема в rhel 7.3 с ansible 2.2.0.0.

Задача в моей пьесе выглядит так:

- name: Restore database
  mysql_db:
    name: db_name
    state: import
    target: /tmp/db_dump.sql.bz2

Во время запуска playbook я получаю следующее сообщение об ошибке:

TASK [role-name : Restore database] ******************************************
fatal: [xx.xx.xx.xx]: FAILED! => {"changed": false, "failed": true, "msg": "\nbzip2: I/O or other error, bailing out.  Possible reason follows.\nbzip2: Broken pipe\n\tInput file = /tmp/db_dump.sql.bz2, output file = (stdout)\n"}

Я не знаю, как отлаживать доступный модуль. Если я могу предоставить какую-либо полезную информацию, скажите, как это сделать.

С Уважением,
Тронда

Всем привет,
Не уверен, что именно с этими ярлыками. Но помните, что версия 2.2 тоже затронута.

@Tronde Я все еще не могу воспроизвести эту ошибку, используя последнюю версию. Можете ли вы попробовать воспроизвести с помощью последней разработки, я выполнил приведенные выше инструкции, любую сжатую базу данных, размер которой в сжатом виде превышает 3,5 МБ.

[root<strong i="7">@phy01</strong> ~]# ansible -i localhost localhost -m mysql_db -a "state=dump target=/tmp/db.sql.bz2 name=diaspora"                                                                               
 [WARNING]: Host file not found: localhost

 [WARNING]: provided hosts list is empty, only localhost is available

localhost | SUCCESS => {
    "changed": true, 
    "db": "diaspora", 
    "msg": ""
}


[root<strong i="8">@phy01</strong> ~]# ansible -i /tmp/hosts all -m mysql_db -a "name=icannotreproducethisbug state=import target=/tmp/db.sql.bz2"
centos7.soh.re | SUCCESS => {
    "changed": true, 
    "db": "icannotreproducethisbug", 
    "msg": ""
}



[root<strong i="9">@centos7</strong> ~]# ls -ltrh /tmp/db.sql.bz2 
-rw-r--r--. 1 root root 79M Jan 24 15:23 /tmp/db.sql.bz2

[root<strong i="10">@phy01</strong> ~]# rpm -qa ansible
ansible-2.3.0-100.git201701131819.d25a708.devel.el7.centos.noarch

@ansibot 'needs_info'

@Jmainguy Мне удалось воспроизвести проблему с последней версией:
~$ ansible-playbook - версияansible-playbook 2.3.0 (devel 6a6fb28af5) последнее обновление 2017/01/24 18:33:11 (GMT +200)файл конфигурации = /etc/ansible/ansible.cfgсконфигурированный путь поиска модуля = по умолчанию без переопределений~

Запуск $ ansible-playbook my-it-brain.yml с задачей:
~~~

• имя: Восстановить базу данных
  mysql_db:
  имя: my_db
  состояние: импорт
  цель: /tmp/my_db.sql.bz2
  ~~~

приводит к:
~ЗАДАЧА [имя-роли: Восстановить базу данных] * * * * * * * * * * * * **фатальный: [10.0.2.4]: НЕ ВЫПОЛНЕНО!

~$ ll ролей / my-it-brain / files /всего 129332-rw-rw-r--.
1 tronde tronde 122675935 10 января 13:18 another_file.tar.bz2~

Скажите, пожалуйста, если вам нужна дополнительная информация.

Я тестирую centos7 с помощью mariadb-server, вы тестируете другую БД? явно что-то между нашими двумя настройками env, потому что я не могу воспроизвести это. Я просто скомпилировал и снова установил последнюю версию, чтобы убедиться.

[root<strong i="6">@phy01</strong> test]# ansible-playbook -i hosts  mysql_db.py 

PLAY [Please break] ************************************************************

TASK [import a bz2 file and break hopefully] ***********************************
changed: [centos7.soh.re]

PLAY RECAP *********************************************************************
centos7.soh.re             : ok=1    changed=1    unreachable=0    failed=0   

[root<strong i="7">@phy01</strong> test]# cat mysql_db.py 
---

- name: Please break
  hosts: all
  gather_facts: false
  tasks:
    - name: import a bz2 file and break hopefully
      mysql_db:
        name: my_db
        state: import
        target: /tmp/db.sql.bz2
[root<strong i="8">@phy01</strong> test]# rpm -qa ansible
ansible-2.3.0-100.git201701241457.8d4246c.devel.el7.centos.noarch

[root<strong i="9">@centos7</strong> ~]# ls -ltrh /tmp/db.sql.bz2
-rw-r--r--. 1 root root 79M Jan 24 15:23 /tmp/db.sql.bz2
[root<strong i="10">@centos7</strong> ~]# rpm -qa | grep -i maria
mariadb-5.5.52-1.el7.x86_64
mariadb-server-5.5.52-1.el7.x86_64
mariadb-libs-5.5.52-1.el7.x86_64

Возможно ли, что bz2 не может распаковать из-за недостатка диска или чего-то еще? Почему bz2 не работает в вашем окружении (и других тестерах, воспроизводящих это)? bzip2: ошибка ввода-вывода или другая ошибка, выход из строя.

Привет,

вот некоторая информация о моем env.

Контроллер:
~$ cat / etc / redhat-releaseRed Hat Enterprise Linux Server выпуск 7.3 (Maipo)~

Целевой узел:
~~~
$ lsb_release -a
Модулей LSB нет.
Идентификатор распространителя: Ubuntu
Описание: Ubuntu 14.04.5 LTS
Релиз: 14.04
Кодовое имя: надежный

$ dpkg -l mysql-сервер
Желаемый = Неизвестно / Установить / Удалить / Очистить / Удерживать
| Статус = Not / Inst / Conf-files / Unpacked / halF-conf / Half-inst / trig-aWait / Trig-pend
| / Err? = (Нет) / Reinst-required (Status, Err: uppercase = bad)
|| / Название Версия Архитектура Описание
+++ - =========================== - ================== - ================== - ============================== ==============================
ii mysql-server 5.5.54-0ubuntu0.14 весь сервер баз данных MySQL (метапакет зависит от последней версии v
~~~

На узле должно быть достаточно места на диске и оперативной памяти для извлечения файла bz2:
~df -hИспользуемый размер файловой системы Доступность% Установлено наudev 486M 4.0K 486M 1% / devtmpfs 100M 476K 99M 1% / запуск/ dev / sda1 12 ГБ 1,8 ГБ 9,4 ГБ 16% /нет 4.0K 0 4.0K 0% / sys / fs / cgroupнет 5,0 млн 0 5,0 млн 0% / запуск / блокировканет 497M 0 497M 0% / погон / шмнет 100 млн 0 100 млн 0% / запуск / пользователь~

Я увеличил объем памяти до 2048 МБ, чтобы избежать проблем с нехваткой памяти. Но я все еще получаю то же сообщение об ошибке.

Я понятия не имею, почему я не могу воспроизвести это, можете ли вы попробовать вручную bunzip2 этот файл и посмотреть, выдает ли он ошибку ввода-вывода?

Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-32-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Tue Jan 24 20:07:20 CET 2017

  System load:  0.25              Processes:           86
  Usage of /:   4.2% of 38.02GB   Users logged in:     0
  Memory usage: 17%               IP address for eth0: 192.168.122.237
  Swap usage:   0%

  Graph this data and manage this system at:
    https://landscape.canonical.com/

New release '16.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

*** System restart required ***
Last login: Tue Jan 24 20:07:20 2017 from 192.168.122.1
root<strong i="6">@ubuntu1404</strong>:~# df -Th
Filesystem                      Type      Size  Used Avail Use% Mounted on
udev                            devtmpfs  487M  8.0K  487M   1% /dev
tmpfs                           tmpfs     100M  432K   99M   1% /run
/dev/mapper/ubuntu1404--vg-root ext4       39G  1.8G   35G   5% /
none                            tmpfs     4.0K     0  4.0K   0% /sys/fs/cgroup
none                            tmpfs     5.0M     0  5.0M   0% /run/lock
none                            tmpfs     498M     0  498M   0% /run/shm
none                            tmpfs     100M     0  100M   0% /run/user
/dev/sda1                       ext2      236M   40M  184M  18% /boot
root<strong i="7">@ubuntu1404</strong>:~# ls -ltrh /tmp/
total 79M
-rw-r--r-- 1 root root 79M Jan 24 20:07 db.sql.bz2
root<strong i="8">@ubuntu1404</strong>:~# bunzip /tmp/db.sql.bz2 
No command 'bunzip' found, did you mean:
 Command 'runzip' from package 'rzip' (universe)
 Command 'funzip' from package 'unzip' (main)
 Command 'ebunzip' from package 'eb-utils' (universe)
 Command 'unzip' from package 'unzip' (main)
 Command 'bunzip2' from package 'bzip2' (main)
 Command 'gunzip' from package 'gzip' (main)
 Command 'lunzip' from package 'lunzip' (universe)
bunzip: command not found
root<strong i="9">@ubuntu1404</strong>:~# bunzip2 /tmp/db.sql.bz2 
root<strong i="10">@ubuntu1404</strong>:~# ls -ltrh /tmp/
total 123M
-rw-r--r-- 1 root root 123M Jan 24 20:07 db.sql
root<strong i="11">@ubuntu1404</strong>:~# dpkg -l mysql-server
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                      Version                   Architecture              Description
+++-=========================================-=========================-=========================-========================================================================================
un  mysql-server                              <none>                    <none>                    (no description available)
root<strong i="12">@ubuntu1404</strong>:~# mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 45
Server version: 5.5.54-0ubuntu0.14.04.1 (Ubuntu)

Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| my_db              |
| mysql              |
| performance_schema |
+--------------------+
4 rows in set (0.00 sec)

mysql> Bye
root<strong i="13">@ubuntu1404</strong>:~# free -m
             total       used       free     shared    buffers     cached
Mem:           994        839        154          0         30        527
-/+ buffers/cache:        281        712
Swap:         1023          3       1020

Использование bunzip2 для локального извлечения файла на целевом узле отлично работает без каких-либо ошибок.

К сожалению, я не знаю, как помочь вам воспроизвести эту ошибку. :-(

Я не могу воспроизвести эту ошибку. При этом, предположим, что он действительно существует, это связано с окончанием stdout до того, как инструмент сжатия сочтет это необходимым. Предполагается, что закончился RAM / Swap.

Я добавил этот код https://github.com/ansible/ansible/commit/1608163b26611171406b3d53135cf4aee63f1765

Что было отменено с помощью этого кода https://github.com/ansible/ansible/commit/aa79810cc83f9f76a2cb9c117782b93056c5487f

Таким образом, похоже, что переход от распаковки в файл, импорта, затем сжатия резервной копии был запрещен для распаковки в стандартный вывод, а затем импорта из этого стандартного вывода.

Я предполагаю, что возврат к диску исправит это за счет скорости и дискового пространства во время работы playbook (он сжимается после импорта).

Мысли?

Предполагается, что закончился RAM / Swap.

Что ж, сегодня я попробую еще раз. Используя два разных дампа mysql, я обнаружил ту же ошибку. В обоих случаях у меня оставалось не менее 120 МБ оперативной памяти. Я думал, этого должно быть достаточно.

Мое понимание этого вопроса недостаточно информировано, чтобы дать вам какие-либо полезные мысли по этому поводу. Но если вы вернетесь к диску, я буду счастлив запустить его еще раз.

Здравствуйте,
После обновления до ansible v2.2.1.0-1 импорт работает:

 - name: Import DB
   mysql_db: name=testdb state=import target=/var/tmp/testdb.sql.bz2

Привет, к сожалению, я все еще получаю ошибку «gzip: stdout: Broken pipe», когда пытаюсь импортировать сжатый дамп GZ. Импорт из несжатого дампа MySQL отлично разветвляется:

...
TASK [Import DB] ***************************************************************
fatal: [db.example.com]: FAILED! => {"changed": false, "failed": true, "msg": "\ngzip: stdout: Broken pipe\n"}
...

...
fatal: [db.example.com]: FAILED! => {
    "changed": false, 
    "failed": true, 
    "invocation": {
        "module_args": {
            "collation": "", 
            "config_file": "/root/.my.cnf", 
            "connect_timeout": 30, 
            "encoding": "", 
            "login_host": "localhost", 
            "login_password": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER", 
            "login_port": 3306, 
            "login_unix_socket": null, 
            "login_user": "root", 
            "name": "my_db", 
            "quick": true, 
            "single_transaction": false, 
            "ssl_ca": null, 
            "ssl_cert": null, 
            "ssl_key": null, 
            "state": "import", 
            "target": "/media/my_db.sql.gz"
        }, 
        "module_name": "mysql_db"
    }, 
    "msg": "\ngzip: stdout: Broken pipe\n"
}
...

$ ansible --version
ansible 2.2.1.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides

# file /media/my_db.sql.gz
/media/my_db.sql.gz: gzip compressed data, last modified: Fri Feb 24 12:03:25 2017, from Unix

# gzip --version
gzip 1.6
...

# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.7 (jessie)
Release:    8.7
Codename:   jessie

Могу подтвердить, получив "gzip: stdout: Broken pipe".
`` фатальный: [zabbix-proxy1]: НЕ ПРОШЛО! => {
"изменено": ложь,
"не удалось": правда,
"invocation": {
"module_args": {
"сопоставление": "",
"config_file": "/root/.my.cnf",
"connect_timeout": 30,
"кодировка": "",
"login_host": "localhost",
"login_password": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"логин_порт": 3306,
"login_unix_socket": ноль,
"login_user": "zabbix",
"name": "zabbix",
"quick": правда,
"single_transaction": ложь,
"ssl_ca": ноль,
"ssl_cert": ноль,
"ssl_key": ноль,
"состояние": "импорт",
"цель": "/usr/share/doc/zabbix-proxy-mysql/schema.sql.gz"
},
"имя_модуля": "mysql_db"
},
"msg": "ngzip: stdout: Broken pipen"
}

```$ ansible --version
ansible 2.2.1.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides

Целевой узел
`` $ lsb_release -a
Модулей LSB нет.
Идентификатор распространителя: Ubuntu
Описание: Ubuntu 16.04.2 LTS
Релиз: 16.04
Кодовое имя: xenial

$ файл /usr/share/doc/zabbix-proxy-mysql/schema.sql.gz
/usr/share/doc/zabbix-proxy-mysql/schema.sql.gz: сжатые данные gzip, были "schema.sql", последнее изменение: среда, 21 декабря, 08:11:14 2016, из Unix
``

Есть новости по этой проблеме?

Привет,
Проблема в том, что @Jmainguy не удалось воспроизвести проблему. Я читал, что ansible 2.3.0 был выпущен в последние дни. Как только эта версия станет доступной в EPEL, я снова протестирую модуль, чтобы увидеть, существует ли проблема.

В моем случае у меня была та же ошибка, что и у OP, но когда я попытался вручную загрузить файл на удаленном компьютере ( bunzip2 -c file.tar.bz2 | mysql db ), я получил ошибку: MySQL has gone away - проблема была max_allowed_packet слишком маленький.

HTH.

По-видимому, эта проблема появляется только в том случае, если база данных уже импортирована (при втором и каждом следующем запуске). Могло быть более идемпотентным ..

Хочу добавить «я тоже» к этому вопросу. Я импортирую файл SQL в формате GZip и получаю Broken Pipe. Моя БД составляет 54 МБ в сжатом виде, ~ 400 МБ без сжатия. Использование ansible 2.3 в WSL. Целевым окном является Ubuntu 16.04.2 / MariaDB 10. Временным решением на данный момент является распаковка файла db с помощью задачи оболочки (поскольку разархивирование не поддерживает эту операцию), а затем импорт.

Привет, ребята, вот еще одна причина ошибки сломанной трубы. Может быть, это помогает некоторым из проблем, описанных выше?

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

По сути, модуль mysql_db выполняет:

        # cmd looks something like:
        cmd = ['mysql','--user=%s' % pipes.quote(user), '--password=%s' % pipes.quote(pass), ... ]
        # comp_prog_path is the compression tool based on target ext (gzip, bzip, etc)
        p1 = subprocess.Popen([comp_prog_path, '-dc', target], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        p2 = subprocess.Popen(cmd, stdin=p1.stdout, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        (stdout2, stderr2) = p2.communicate()
        p1.stdout.close()
        p1.wait()
        if p1.returncode != 0:
            stderr1 = p1.stderr.read()
            return p1.returncode, '', stderr1
        else:
            return p2.returncode, stdout2, stderr2

Итак, когда пароль - test1234!, Ansible пытается передать ['mysql','--user=admin',"--password='test1234!'",'-D','testdb'] в подпроцесс. (Обратите внимание на кавычки вокруг пароля)

Когда exec передает это mysql, Mysql терпит неудачу с ERROR 1045 (28000): Access denied for user 'admin'@'x.x.x.x' (using password: YES) , и оба p1 и p2 возвращают ненулевые ошибки. К сожалению, ansible возвращает только ошибку сломанного канала (из команд gzip, bzip и т. Д.).

Я обезьяна исправил мою версию mysql_db.py, чтобы удалить pipe.quote () из пароля, и все работало нормально.

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

1) только возвращает ошибку p1, если канал не был сломан (не уверен, что лучший способ справиться с этим с подпроцессом, но bash делает это правильно: gzip -dc foo.gz | mysql --password='wrong' не показывает ошибку сломанного канала для gzip.)
2) не использовать pipe.quote () для паролей

Для этого отправлен PR # 26504.

Есть ли шанс, что мы сможем внести исправление в серию 2.3?

копи @Xyon @michaelcoburn @oneiroi @tolland
нажмите здесь, чтобы получить помощь по ботам

cc @bmildren
нажмите здесь, чтобы получить помощь по ботам

cc @ Alexander198961
нажмите здесь, чтобы получить помощь по ботам

cc @ Andersson007
нажмите здесь, чтобы получить помощь по ботам

cc @kurtdavis
нажмите здесь, чтобы получить помощь по ботам

Время подходящее всем привет,
Я хотел бы предоставить новую информацию по этому вопросу.

Информация о тестовом примере

Я использовал сжатый bzip2 файл дампа MySQL и попытался импортировать его в две разные целевые системы.

Узел управления Ansible

Red Hat Enterprise Linux Server, выпуск 7.7 (Maipo)
ненадежный 2.9.6
файл конфигурации = /etc/ansible/ansible.cfg
настроенный путь поиска модуля = [u '/ home / tronde / .ansible / plugins / modules', u '/ usr / share / ansible / plugins / modules']
расположение модуля ansible python = /usr/lib/python2.7/site-packages/ansible
расположение исполняемого файла = / usr / bin / ansible
версия python = 2.7.5 (по умолчанию, 11 июня 2019 г., 14:33:56) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]

Целевые узлы

1. Debian Buster (текущий уровень патча)
2. CentOS 7.7 (текущий уровень исправлений)

Сценарий 1: Успешное развертывание в Debian Buster

Пособие

---

- name: Test case to debug mysql_db module
  hosts: 10.0.2.6
  tasks:
    - name: Copy database dump file
      copy:
        src: /tmp/test-case.sql.bz2
        dest: /tmp

    - name: Restore database
      mysql_db:
        name: test-case-db
        state: import
        target: /tmp/test-case.sql.bz2

Тестовый файл

-rwxr-xr-x. 1 1000 1000 12445232 Mar 17 20:40 /tmp/test-case.sql.bz2

Playbook запустить

PLAY [Test case to debug mysql_db module] **************************************

TASK [Gathering Facts] *********************************************************
ok: [10.0.2.6]

TASK [Check for nginx, php-fpm and mysql-server] *******************************
changed: [10.0.2.6]

TASK [Copy database dump file] *************************************************
changed: [10.0.2.6]

TASK [Restore database] ********************************************************
changed: [10.0.2.6]

PLAY RECAP *********************************************************************
10.0.2.6                   : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Все отлично.

Сценарий 2: неудачное развертывание на CentOS 7.7

Playbook и тестовый файл такие же, как в сценарии 1.

Playbook запустить

PLAY [Test case to debug mysql_db module] **************************************

TASK [Gathering Facts] *********************************************************
ok: [10.0.2.15]

TASK [Copy database dump file] *************************************************
changed: [10.0.2.15]

TASK [Restore database] ********************************************************
fatal: [10.0.2.15]: FAILED! => {"changed": false, "msg": "\nbzip2: I/O or other error, bailing out.  Possible reason follows.\nbzip2: Broken pipe\n\tInput file = /tmp/test-case.sql.bz2, output file = (stdout)\n"}

PLAY RECAP *********************************************************************
10.0.2.15                  : ok=4    changed=3    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

Запуск bunzip2 /tmp/test-case.sql.bz2 на целевом узле завершился без ошибок.

Если вам нужна дополнительная информация, скажите, пожалуйста, какие и как их собрать.

С Уважением,
Тронда

Привет @Tronde и другие
https://github.com/ranger/ranger/issues/325 Я обнаружил аналогичную проблему (supbrocess).
Люди сказали, что ошибка появляется, когда они используют python2, и исчезают с python3.
Я также обнаружил, что https://stackoverflow.com/questions/295459/how-do-i-use-subprocess-popen-to-connect-multiple-processes-by-pipes, где упоминалось, что broken pipe может произойти, потому что Существуют разные сигналы, которые используются оболочками Linux и модулем подпроцесса.

Кто может воспроизвести проблему, не могли бы вы создать simlink python → python3, чтобы принудительно использовать его, а затем проверить.
Если он работает нормально, это означает, что это проблема не доступного, а модуля подпроцесса в python2, и мы могли бы сделать отметку в документации модуля, чтобы вместо этого принудительно использовать python3

(символическая ссылка на целевой машине)

Кто может воспроизвести проблему, не могли бы вы создать simlink python → python3, чтобы принудительно использовать его, а затем проверить.

Нет необходимости использовать символическую ссылку, достаточно указать ansible_python_interpreter
См. Https://docs.ansible.com/ansible/latest/reference_appendices/interpreter_discovery.html

@bmalynovytch круто, спасибо за подсказку!

Привет, из-за # 67083 я не могу проверить с python3.

@Tronde, может быть, клонировать виртуальную машину и установить python3 вручную?

если это невозможно, может ли кто-нибудь еще попытаться воспроизвести ошибку с помощью python3 принудительно, как описано выше @bmalynovytch ?

@ Andersson007 Я не буду устанавливать python3 вручную. Но я попробовал другое.

Как мы знаем из моего тестового сценария, развертывание на debian buster прошло успешно. Debian 10 поставляется с python2 и python3. Когда @ Andersson007 прав и проблема возникает только при использовании python2, я смогу воспроизвести проблему после удаления python3 с моей машины buster.

Я сделал это, но развертывание снова было успешным. Поэтому я бы сказал, что извлечение сжатого файла дампа sql с помощью python2 в целом возможно.

Но я заметил, что buster поставляется с python 2.7.16, а CentOS - с 2.7.5.

Я не могу воспроизвести следующие

файл дампа 14 МБ bz2 (несколько ГБ без сжатия)

Работает:

CentOS Linux release 6.10
Kernel 2.6.32-754.el6.x86_64
bzip2-1.0.5-7.el6_0.x86_64
Python 2.7.13rc1 (works with default python 2.6.6-66 too)
PyMySQL-0.9.3
MySQL-python 1.2.5

Работает:

CentOS Linux release 7.7.1908
Kernel 3.10.0-229.el7.x86_64
bzip2 1.0.6-13.el7
python 2.7.5-86.el7 (updated because it was impossible to install pip without it)
PyMySQL-0.9.3

Работает:

(default installation)
CentOS Linux release 7.1.1503
python 2.7.5-16 (default in CentOS 7.1)

но я знаю решение. скоро

https://github.com/ansible-collections/community.general/pull/151
Может ли кто-нибудь попробовать использовать это вместо ваших версий и подтвердить, что ошибка исчезла?

Привет, просто чтобы отметить это и здесь. Я могу подтвердить, что ошибка исчезла, используя код из ansible-collections / community.general # 151 .

@Tronde , спасибо! мы ждем отзывов от других до следующей недели. если никто не возражает против изменений, мы объединим это.

close_me

закрыто через https://github.com/ansible-collections/community.general/pull/151
@Tronde большое спасибо за сообщение и помощь!

Закрытие согласно вышеизложенному.