Closed fjorgemota closed 6 years ago
jfindlay
commented
8 years ago @fjorgemota, thanks for the report. A better place for this issue might be the [https://github.com/saltstack-formulas/mysql-formula/issues/new](mysql formula). Is it possible for you to reproduce the problem with the mysql repo and without using the mysql formula?
fjorgemota
commented
8 years ago Hello, @jfindlay.
I don't think that the mysql-formula is the more appropriate, just because the mysql-formula is not directly responsible by the subprocess that Salt manages (waiting the subprocess to finish, in this case), even when we consider that mysql-formula is causing Salt to start that process.
Another point is that, when a process turns into a zombie, is probably because the parent process (salt-call, in this case) does not have waited nor read (?) the output correctly, and so the zombie process waits the parent process so it can manage the subprocess correctly. Well, that's the known cases I remember for a subprocess turn into a zombie process. If it's a problem of managing the subprocess correctly, how a salt state (which does not evolves python code directly) can cause it?
I suppose that, if a salt state is causing it (in this case, my modified mysql-formula updated to support MySQL 5.7 by downloading mysql from the official repositories), even while it's a bit specific case, that salt state (again, without python code directly evolved) should not cause the subprocess to turn into a zombie process, and so the problem is caused by the module which manages subprocess (or something related to python, I don't know)
Well, that's a bit of "I suppose", but, for the moment, it's the problem I am fighting against and I really don't think that the problem is directly related to mysql-formula, as all the commands run normally when executed in bash, without zombies.
I might try to reproduce the problem with another smaller example, because I really think that the problem should not be just related to mysql-formula, here.
Thanks for the answer, anyway. :)
jfindlay
commented
8 years ago @fjorgemota, yes I should have been more clear on my doubt that the problem was solely caused by the mysql formula. If you can manage to find a more minimal test case that doesn't involve the formula, that would be great.
fjorgemota
commented
8 years ago @jfindlay Right, i'll try to find a more minimal test case for that problem.
Just a fix for the labels: I think that problem is located on cmd module, because, as I said in the original text of the issue, even when running the command using directly the module.run state and calling cmd.retcode (based on some comments I found in some issues here in github) the apt-get program still turns into a zombie.
graffic
commented
8 years ago I just had the same problem with the same package: mysql community server. apt-get becomes a zombie. In this case the formula is hand made.
If you run the commands without salt, mysql installs without a problem.
One thing that the mysql-community-server package does is to output some dots while it configures and install. Perhaps that confuses salt.
syndicut
commented
8 years ago I've had the same issue with https://github.com/saltstack-formulas/bind-formula hanging on Executing command ['apt-get', '-q', '-y', '-o', 'DPkg::Options::=--force-confold', '-o', 'DPkg::Options::=--force-confdef', 'install', 'bind9', 'dnssec-tools', 'bind9utils'] in directory '/root'
fjorgemota
commented
8 years ago By the way, I did not found any "minimal test case" for the problem as I stopped using Salt personally (althrough the software is nice).
I don't think that the solution is related to dots (as @graffic suggested) as I have not seem any command output processing in the module, and even using cmd.run module directly the program still hangs (as far I remember).
By the way, I think the problem related by @syndicut will probably be simpler to test because it seems to appear in a official formula, but more testing is necessary.
Good luck anyway. :+1:
Enchiridion
commented
8 years ago I'm having the exact same issue installing mysql-server on a Vagrant box.
I think I've found as minimal a test case as I can build:
mysql_server:
pkg.installed:
- name: mysql-server
- refresh: True
- require:
- pkg: mysql_apt_config
mysql_apt_config:
pkg.installed:
- sources:
- mysql-apt-config: /tmp/mysql-apt-config_0.7.2-1_all.deb
- require:
- file: mysql_repo_apt_config_package_file
- debconf: mysql_apt_config_settings
- debconf: mysql_server_settings
mysql_repo_apt_config_package_file:
file.managed:
- name: /tmp/mysql-apt-config_0.7.2-1_all.deb
- source: http://dev.mysql.com/get/mysql-apt-config_0.7.2-1_all.deb
- source_hash: sha1=8649b52da5a6e9d2245e1a5ca0fedb8e8a8b74ce
mysql_apt_config_settings:
debconf.set:
- name: mysql-apt-config
- data:
'mysql-apt-config/select-server' : {'type' : 'select', 'value' : 'mysql-5.7'}
'mysql-apt-config/select-workbench' : {'type' : 'select', 'value' : 'none'}
'mysql-apt-config/select-tools' : {'type' : 'select', 'value' : ''}
'mysql-apt-config/select-preview' : {'type' : 'select', 'value' : ''}
'mysql-apt-config/select-product' : {'type' : 'select', 'value' : 'Ok'}
mysql_server_settings:
debconf.set:
- name: mysql-server
- data:
'mysql-server/root-pass' : {'type' : 'password', 'value' : 'foobar'}
'mysql-server/re-root-pass' : {'type' : 'password', 'value' : 'foobar'}
'mysql-server/mysql-server/root_password' : {'type' : 'password', 'value' : 'foobar'}
'mysql-server/mysql-server/root_password_again' : {'type' : 'password', 'value' : 'foobar'}When I covert this into an equivalent shell script or manually run the commands it works perfectly.
Figuring out what the process is hanging on is beyond me.
Version info:
vagrant@salt:~$ salt-minion --versions-report
Salt Version:
Salt: 2015.8.8.2
Dependency Versions:
Jinja2: 2.7.2
M2Crypto: Not Installed
Mako: 0.9.1
PyYAML: 3.10
PyZMQ: 14.0.1
Python: 2.7.6 (default, Jun 22 2015, 17:58:13)
RAET: Not Installed
Tornado: 4.2.1
ZMQ: 4.0.4
cffi: Not Installed
cherrypy: Not Installed
dateutil: 1.5
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
libgit2: Not Installed
libnacl: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.3.0
mysql-python: 1.2.3
pycparser: Not Installed
pycrypto: 2.6.1
pygit2: Not Installed
python-gnupg: Not Installed
smmap: Not Installed
timelib: Not Installed
System Versions:
dist: Ubuntu 14.04 trusty
machine: x86_64
release: 3.19.0-25-generic
system: Ubuntu 14.04 trusty@Enchiridion, thanks for the test case.
zerthimon
commented
8 years ago This has nothing to do with formula. I have a minimalistic SLS in the referenced issue.
zerthimon
commented
8 years ago Woraround in https://github.com/saltstack/salt/issues/33442
stale[bot]
commented
6 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.
Hello! Good reading of the issue below, I hope that I described the problem well...:)
TLDR
When using pkg.installed in one of my states, which install a package found in mysql official apt repository, the package is installed correctly, but apt-get turns into a zombie process and the salt-call calling highstate justs hang-on, even when using module.run to execute cmd.retcode. If running exactly the same code that Salt executes manually via ssh, the apt-get does not turn into a zombie process and the package is installed correctly too. The apt-get call just turns into a zombie when Salt manages it.
Versions
Below is the result of
salt-minion --versions-reportcall. (there is no master because Vagrant is managing it)Full description
I'm trying to create a developer environment in my machine using Vagrant to manage Virtualbox's machines and Saltstack to install and configure all the needed packages in it. For MySQL, i'm using mysql-formula with some modifications to allow the use of MySQL Official APT Repositories, such as changes in
debconf.setcall present in server.sls and changes in defaults.yaml. Here is the repository with the changes (note that, because I just want to use that formula in a Ubuntu machine (14.04 LTS version, btw), I'm not very interested in the support to other operating systems now) When using that formula with the following top file:Everything seems to run fine, the MySQL Official APT Repository is correctly defined in the system and an
apt-get -q updateis executed to update the system's sources, but, when Salt try to install mysql-community-server, the daemon just hangs, and the last printed log is that:[INFO ] Executing command ['apt-get', '-q', '-y', '-o', 'DPkg::Options::=--force-confold', '-o', 'DPkg::Options::=--force-confdef', 'install', 'mysql-community-server'] in directory '/root'.When executing htop on the virtual machine (I manually installed via ssh), all I see is the following:
But, when running
sudo service mysql status, I have a surprise:So, MySQL is correctly installed, and is correctly running, but...hey, Salt does not detected it, and just hang on awaiting something I cannot imagine of..
Alternatives tried
I tried changing these lines to a module.run executing cmd.retcode module with the cmd being the same that Salt try to execute (based on some issues found here), but the apt-get turn into a zombie and Salt just hang-on again.
And...when configuring debconf the same way Salt configures and executing the same command that Salt executes via SSH, I just...found the install running successfully, no zombies, MySQL installed and correctly running. So...seems (to me) to be some problem with subprocess management of Salt..
Can anyone help me to solve this case, please?
Thanks. (and sorry for my bad english, I'm a bit bored after trying to solve this problem two days in a row..)
PS: Most of the changes made in mysql-formula by me is based on Dockerfile that installs MySQL from the official source in a container based on Debian, and can be found here.