[Bug / Regression] mysql_db import fail to decompress dumps #20196

Tronde · 2017-01-12T20:43:05Z

From @bmalynovytch on June 2, 2016 15:43

ISSUE TYPE

Bug Report (regression)

COMPONENT NAME

mysql_db (import)

ANSIBLE VERSION

ansible 2.1.0.0
  config file = /Users/benjamin/xxxxxxx/ansible.cfg
  configured module search path = Default w/o overrides

CONFIGURATION

[defaults]
host_key_checking = False
forks=500
pipelining=True
retry_files_enabled = False

gathering = smart
fact_caching = jsonfile
fact_caching_connection = ./.tmp/ansible
fact_caching_timeout = 3600

[ssh_connection]
control_path = /tmp/ansible-ssh-%%h-%%p-%%r
ssh_args = -o ControlMaster=auto -o ControlPersist=30m

OS / ENVIRONMENT

Deployment OS: Mac OS X 10.11.5, python v2.7.11 with pyenv/virtualenv
Destination OS: ubuntu jessie/sid

SUMMARY

Using mysql_db to import Gzipped or Bzipped SQL dumps used to work like a charm with ansible 2.0.2.0
Now, compressed imports fail with a broken pipe error, either if .gz or .bz2
Strangely, this does not happen on a small (compressed) file (1.8k gzip compressed, 6k uncompressed)
Maybe related to https://blog.nelhage.com/2010/02/a-very-subtle-bug/

STEPS TO REPRODUCE

Try to import a compressed (large enough) SQL dump with mysql_db.
Failure happen with a 3.5MB gzip compressed / 20MB uncompressed dump.

- name: Restore database
  mysql_db:
  args:
    name: my_db
    state: import
    target: /path_to_backups/backup-pre-release.sql.bz2
    login_host: "{{ db.host }}"
    login_port: "{{ db.port }}"
    login_user: "{{ db.user }}"
    login_password: "{{ db.passwd }}"

EXPECTED RESULTS

Import should just work.

ACTUAL RESULTS

fatal: [xxxxxx]: FAILED! => {"changed": false, "failed": true, 
"msg": 
"bzip2: I/O or other error, bailing out.  Possible reason follows.
 bzip2: Broken pipe
       Input file = /opt/xxxxxx/backup-pre-release.sql.bz2, output file = (stdout)
"}

Copied from original issue: ansible/ansible-modules-core#3835

The text was updated successfully, but these errors were encountered:

Tronde · 2017-01-12T20:43:06Z

From @ansibot on July 30, 2016 16:32

@Jmainguy ping, this issue is waiting for your response.
click here for bot help

Tronde · 2017-01-12T20:43:07Z

From @Jmainguy on July 30, 2016 20:10

I tried to recreate this on ansible-2.2.0-0.git201605131739.e083fa3.devel.el7.centos.noarch and was unable to reproduce.

imported a 240mb .tar.gz (took a few hours, but it worked).

This was on centos, can you try again with devel on ubuntu and let me know if this is still happening?

Tronde · 2017-01-12T20:43:07Z

From @ansibot on September 8, 2016 20:59

@Jmainguy, ping. This issue is still waiting on your response.
click here for bot help

Tronde · 2017-01-12T20:43:08Z

From @Jmainguy on September 9, 2016 18:19

ansibot "needs_info"

Tronde · 2017-01-12T20:43:08Z

From @bmalynovytch on September 9, 2016 19:3

The bug concerns any size of compressed dumps: the module doesn't uncompress them anymore.
It might have been fixed, in recent versions, but I don't have time to give it a try, as the platforms on which I use the mysql_db module now handle uncompression before calling mysql_db, and I'm not working on them for now.
I don't have time to test that part again for the moment, sorry.

!needs_info

Tronde · 2017-01-12T20:43:08Z

From @ilyapoz on September 27, 2016 18:24

Any workarounds so far? Still reproducible on ubuntu trusty in a virtualbox
ansible 2.1.1.0

Tronde · 2017-01-12T20:43:09Z

From @ansibot on September 27, 2016 18:43

@Jmainguy, ping. This issue is still waiting on your response.
click here for bot help

Tronde · 2017-01-12T20:43:09Z

From @ilyapoz on September 27, 2016 18:44

Sorry, a possible workaround for small db's is not compressing the dump

Tronde · 2017-01-12T20:43:09Z

From @ansibot on December 9, 2016 19:50

This repository has been locked. All new issues and pull requests should be filed in https://github.com/ansible/ansible

Please read through the repomerge page in the dev guide. The guide contains links to tools which automatically move your issue or pull request to the ansible/ansible repo.

Tronde · 2017-01-12T20:43:10Z

From @ulrith on December 20, 2016 11:35

I have the same behavior with my Ansible 2.2.0.0 on Ubuntu 16.04.
Funny but the 'unarchive' module task also fails if I try to decompress the archive before feeding a dump to the mysql_db module. >:-<
Too bad...

Tronde · 2017-01-12T20:43:10Z

From @sachavuk on January 4, 2017 17:38

Hi,

I have the same issue on Debian 7.8 with ansible 2.2.0.0 the same error message 😢

Tronde · 2017-01-12T20:52:36Z

Good evening,
I hope it was correct to move the issue to this repo as suggested in Move Issues and PRs to new Repo.

As @ulrith and @sachavuk I have this issue, too. In my case the issue is in rhel 7.3 with ansible 2.2.0.0.

The task in my play looks like:

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

During the playbook run I receive the following error message:

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

I don't know how to debug an ansible module. If there are any useful information I could provide, please tell me how to do that.

Regards,
Tronde

Tronde · 2017-01-13T18:43:08Z

Hi there,
Not sure what's up exactly with these labels. But remember that version 2.2 is affected, too.

Jmainguy · 2017-01-24T15:28:22Z

@Tronde I am still unable to reproduce this bug using latest devel. Can you try and reproduce using latest devel, I followed the instructions above, any compressed database that is larger than 3.5mb when compressed.

[root@phy01 ~]# 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@phy01 ~]# 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@centos7 ~]# ls -ltrh /tmp/db.sql.bz2 
-rw-r--r--. 1 root root 79M Jan 24 15:23 /tmp/db.sql.bz2

[root@phy01 ~]# rpm -qa ansible
ansible-2.3.0-100.git201701131819.d25a708.devel.el7.centos.noarch

Jmainguy · 2017-01-24T15:30:37Z

@ansibot 'needs_info'

Tronde · 2017-01-24T17:49:56Z

@Jmainguy I was able to reproduce the problem with the latest devel:

$ ansible-playbook --version
ansible-playbook 2.3.0 (devel 6a6fb28af5) last updated 2017/01/24 18:33:11 (GMT +200)
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides

Running $ ansible-playbook my-it-brain.yml with the task:

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

results in:

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

$ ll roles/my-it-brain/files/
total 129332
-rw-rw-r--. 1 tronde tronde   9754808 Jan  8 20:45 my_db.sql.bz2
-rw-rw-r--. 1 tronde tronde 122675935 Jan 10 13:18 another_file.tar.bz2

Please tell me, if you need further information.

Jmainguy · 2017-01-24T18:05:18Z

I am testing against centos7 with mariadb-server, are you testing against another DB? there is clearly something between our two env setups because I am unable to reproduce this. I just compiled and installed latest devel again to be sure.

[root@phy01 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@phy01 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@phy01 test]# rpm -qa ansible
ansible-2.3.0-100.git201701241457.8d4246c.devel.el7.centos.noarch

[root@centos7 ~]# ls -ltrh /tmp/db.sql.bz2
-rw-r--r--. 1 root root 79M Jan 24 15:23 /tmp/db.sql.bz2
[root@centos7 ~]# 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

Is it possible bz2 is failing to uncompress because of disk running out or something? Why is bz2 failing in your (and other testers reproducing this) envs? bzip2: I/O or other error, bailing out.

Tronde · 2017-01-24T18:37:36Z

Hi,

here are some information about my env.

Controller:

$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.3 (Maipo)

Target Node:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.5 LTS
Release:	14.04
Codename:	trusty

$ 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
+++-===========================-==================-==================-============================================================
ii  mysql-server                5.5.54-0ubuntu0.14 all                MySQL database server (metapackage depending on the latest v

The node should have enough disk space and ram to extract the bz2 file:

df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            486M  4.0K  486M   1% /dev
tmpfs           100M  476K   99M   1% /run
/dev/sda1        12G  1.8G  9.4G  16% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            497M     0  497M   0% /run/shm
none            100M     0  100M   0% /run/user

I increased the memory to 2048 mb to be sure not to run in an out of memory issue. But I'm still getting the same error message.

Jmainguy · 2017-01-24T19:13:59Z

I have no idea why I cannot reproduce this, can you try manually bunzip2 that file and see if it shoots the i/o error?

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@ubuntu1404:~# 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@ubuntu1404:~# ls -ltrh /tmp/
total 79M
-rw-r--r-- 1 root root 79M Jan 24 20:07 db.sql.bz2
root@ubuntu1404:~# 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@ubuntu1404:~# bunzip2 /tmp/db.sql.bz2 
root@ubuntu1404:~# ls -ltrh /tmp/
total 123M
-rw-r--r-- 1 root root 123M Jan 24 20:07 db.sql
root@ubuntu1404:~# 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@ubuntu1404:~# 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@ubuntu1404:~# free -m
             total       used       free     shared    buffers     cached
Mem:           994        839        154          0         30        527
-/+ buffers/cache:        281        712
Swap:         1023          3       1020

Tronde · 2017-01-24T20:25:01Z

Using bunzip2 to extract the file locally on the target node works just fine without any error.

Unfortunately I have no idea how to help you reproducing this error. :-(

Jmainguy · 2017-01-24T21:26:21Z

I am unable to reproduce this bug. That being said, supposing it does exist, it has to do with stdout ending before the compression tool thinks it should. Guessing running out of ram / swap.

I added this code 1608163

Which was reverted with this code aa79810

So it seems going from decompressing to file, importing, then compressing back up was nixed for decompressing to stdout, then importing from that stdout.

I imagine going back to disk will fix this, at the cost of speed, and disk space while the playbook is running (it will compress after it imports).

Thoughts?

Tronde · 2017-01-25T19:59:37Z

Guessing running out of ram / swap.

Well, I give it a try again, today. Using two different mysql dumps I encountered the same error. In both cases I had at least 120 MB of ram left. I thought that should be enough.

My understanding of this matter is not informed enough to give you any helpful thoughts on this. But if you are going back to disk, I would be happy to give it another run.

ansibot · 2019-02-19T18:22:05Z

cc @Xyon @michaelcoburn @Oneiroi @tolland
click here for bot help

ansibot · 2019-02-27T19:18:56Z

cc @bmildren
click here for bot help

ansibot · 2019-06-03T22:16:02Z

cc @Alexander198961
click here for bot help

ansibot · 2019-06-19T22:55:40Z

cc @Andersson007
click here for bot help

ansibot · 2019-08-08T16:18:37Z

cc @kurtdavis
click here for bot help

Tronde · 2020-03-17T20:48:23Z

Time appropriate greetings everyone,
I would like to provide some new information to this issue.

Information about the test case

I've used a bzip2 compressed MySQL dump file and tried to import it on two different target systems.

Ansible Control Node

Red Hat Enterprise Linux Server release 7.7 (Maipo)
ansible 2.9.6
config file = /etc/ansible/ansible.cfg
configured module search path = [u'/home/tronde/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python2.7/site-packages/ansible
executable location = /usr/bin/ansible
python version = 2.7.5 (default, Jun 11 2019, 14:33:56) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]

Target nodes

Debian Buster (current patch level)
CentOS 7.7 (current patch level)

Scenario 1: Successful deployment on Debian Buster

Playbook

---

- 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

Test file

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

Playbook run

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

Everything is fine.

Scenario 2: Unsuccessful deployment on CentOS 7.7

Playbook and test file are the same as in scenario 1.

Playbook run

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

Running bunzip2 /tmp/test-case.sql.bz2 on the target node completed without error.

In case you need more information, please tell me which and how to gather them.

Regards,
Tronde

Andersson007 · 2020-04-08T08:04:44Z

Hi @Tronde and others
ranger/ranger#325 I found a similar issue (supbrocess).
People said that the error appears when they use python2 and disappear with python3.
I also found https://stackoverflow.com/questions/295459/how-do-i-use-subprocess-popen-to-connect-multiple-processes-by-pipes where mentioned that broken pipe can happen because there are different signals which are used by linux shells and subprocess module.

Who can reproduce the problem could you please create a simlink python -> python3 to force ansible use it and check then.
If it works ok it means it is not a problem of ansible but of subprocess module in python2 and we might make a note in the module's documentation to use python3 forcibly instead

Andersson007 · 2020-04-08T08:17:05Z

(symlink on the target machine)

bmalynovytch · 2020-04-10T09:32:04Z

Who can reproduce the problem could you please create a simlink python -> python3 to force ansible use it and check then.

No need to use a symlink, just defining ansible_python_interpreter should suffice
See https://docs.ansible.com/ansible/latest/reference_appendices/interpreter_discovery.html

Andersson007 · 2020-04-10T11:01:24Z

@bmalynovytch cool, thanks for the tip!

Tronde · 2020-04-10T11:48:46Z

Hi, due to #67083 I'm not able to check with python3.

Andersson007 · 2020-04-10T11:59:48Z

@Tronde maybe to clone the vm and install python3 manually?

if it's impossible, can anybody else try to reproduce the bug using python3 forcibly as @bmalynovytch described above?

Tronde · 2020-04-10T20:14:48Z

@Andersson007 I won't install python3 manually. But I tried something else.

As we know from my test scenario the deployment on debian buster was successful. Debian 10 is shipped with python2 and python3. When @Andersson007 is right and the issue occurs only when using python2 I should be able to reproduce the issue after I've removed python3 from my buster machine.

I did so but the deployment was successful again. So I would argue that extracting a compressed sql dump file with python2 is possible in general.

But I noticed that buster comes with python 2.7.16 while CentOS is shipping 2.7.5.

Andersson007 · 2020-04-11T12:49:43Z

I can't reproduce with following

dump file 14MB bz2 (several GBs uncompressed)

Works:

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

Works:

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

Works:

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

but i know the solution. coming soon

Andersson007 · 2020-04-11T13:24:14Z

ansible-collections/community.general#151
could anybody please try to use that instead of your versions and confirm the bug disappeared ?

Tronde · 2020-04-16T11:42:35Z

Hi, just to note it here, too. I can confirm that the bug disappeared using the code from ansible-collections/community.general#151.

Andersson007 · 2020-04-16T11:53:21Z

@Tronde , thanks! we're wating for feedback from others until next week. if nobody's resonably against the changes, we'll merge that.

Andersson007 · 2020-04-20T15:48:45Z

close_me

Andersson007 · 2020-04-20T15:49:35Z

closed via ansible-collections/community.general#151
@Tronde thanks much for reporting and helping!

sivel · 2020-04-20T16:30:21Z

Closing per above.

Tronde mentioned this issue Jan 12, 2017

[Bug / Regression] mysql_db import fail to decompress dumps ansible/ansible-modules-core#3835

Closed

ansibot added affects_2.1 This issue/PR affects Ansible v2.1 bug_report needs_triage Needs a first human triage before being processed. labels Jan 12, 2017

nitzmahone added module This issue/PR relates to a module. and removed needs_triage Needs a first human triage before being processed. labels Jan 13, 2017

ansibot added the needs_info This issue requires further information. Please answer any outstanding questions. label Jan 24, 2017

ansibot removed the needs_info This issue requires further information. Please answer any outstanding questions. label Jan 24, 2017

ansibot added the support:community This issue/PR relates to code supported by the Ansible community. label Oct 3, 2018

ansibot removed the needs_maintainer Ansibot is unable to identify maintainers for this PR. (Check `author` in docs or BOTMETA.yml) label Nov 10, 2018

dagwieers added the mysql label Jan 26, 2019

ansibot added the test This PR relates to tests. label Feb 3, 2019

ansibot added the database Database category label Feb 19, 2019

rockpunk added a commit to rockpunk/ansible that referenced this issue Feb 20, 2019

Fix for issue ansible#20196.

925b2d7

Andersson007 mentioned this issue Apr 11, 2020

mysql_db: add use_shell parameter to prevent Broken pipe errors ansible-collections/community.general#151

Merged

ansibot added the has_pr This issue has an associated PR. label Apr 11, 2020

sivel closed this as completed Apr 20, 2020

ansible locked and limited conversation to collaborators May 18, 2020

[Bug / Regression] mysql_db import fail to decompress dumps #20196

[Bug / Regression] mysql_db import fail to decompress dumps #20196

Comments

Tronde commented Jan 12, 2017

ISSUE TYPE

COMPONENT NAME

ANSIBLE VERSION

CONFIGURATION

OS / ENVIRONMENT

SUMMARY

STEPS TO REPRODUCE

EXPECTED RESULTS

ACTUAL RESULTS

Tronde commented Jan 12, 2017

Tronde commented Jan 12, 2017

Tronde commented Jan 12, 2017

Tronde commented Jan 12, 2017

Tronde commented Jan 12, 2017

Tronde commented Jan 12, 2017

Tronde commented Jan 12, 2017

Tronde commented Jan 12, 2017

Tronde commented Jan 12, 2017

Tronde commented Jan 12, 2017

Tronde commented Jan 12, 2017

Tronde commented Jan 12, 2017 • edited

Tronde commented Jan 13, 2017

Jmainguy commented Jan 24, 2017

Jmainguy commented Jan 24, 2017

Tronde commented Jan 24, 2017

Jmainguy commented Jan 24, 2017

Tronde commented Jan 24, 2017

Jmainguy commented Jan 24, 2017

Tronde commented Jan 24, 2017

Jmainguy commented Jan 24, 2017

Tronde commented Jan 25, 2017

ansibot commented Feb 19, 2019

ansibot commented Feb 27, 2019

ansibot commented Jun 3, 2019

ansibot commented Jun 19, 2019

ansibot commented Aug 8, 2019

Tronde commented Mar 17, 2020

Information about the test case

Ansible Control Node

Target nodes

Scenario 1: Successful deployment on Debian Buster

Playbook

Test file

Playbook run

Scenario 2: Unsuccessful deployment on CentOS 7.7

Playbook run

Andersson007 commented Apr 8, 2020

Andersson007 commented Apr 8, 2020

bmalynovytch commented Apr 10, 2020 • edited

Andersson007 commented Apr 10, 2020

Tronde commented Apr 10, 2020

Andersson007 commented Apr 10, 2020

Tronde commented Apr 10, 2020

Andersson007 commented Apr 11, 2020 • edited

Andersson007 commented Apr 11, 2020 • edited

Tronde commented Apr 16, 2020

Andersson007 commented Apr 16, 2020

Andersson007 commented Apr 20, 2020

Andersson007 commented Apr 20, 2020

sivel commented Apr 20, 2020

Tronde commented Jan 12, 2017 •

edited

bmalynovytch commented Apr 10, 2020 •

edited

Andersson007 commented Apr 11, 2020 •

edited

Andersson007 commented Apr 11, 2020 •

edited