Bug 698218 - [vdsm] processPool processes does not always exit when vdsm dies
Summary: [vdsm] processPool processes does not always exit when vdsm dies
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vdsm
Version: 6.1
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Erez Shinan
QA Contact: Jakub Libosvar
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-20 13:04 UTC by Jakub Libosvar
Modified: 2011-12-06 07:14 UTC (History)
5 users (show)

Fixed In Version: vdsm-4.9-66.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 07:14:47 UTC
Target Upstream Version:

Attachments (Terms of Use)
vdsm.log (15.09 MB, application/octet-stream)
2011-04-20 13:04 UTC, Jakub Libosvar 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2011:1782 0 normal SHIPPED_LIVE new packages: vdsm 2011-12-06 11:55:51 UTC

Description Jakub Libosvar 2011-04-20 13:04:26 UTC 
Created attachment 493481 [details]
vdsm.log

Description of problem:
When running rhel6 host in 2.3 cluster in DC 2.2, vdsm is running a few processes on the host. If the parent of those processes is killed, child processes become orphans and keep runnning. Note that DC 2.2 is important in this case, in DC 2.3 there is not that amount of processes.

Version-Release number of selected component (if applicable):
ic114
vdsm-4.9-60.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Have rhel6.x host in DC2.2
2. Kill vdsm
3. Check running vdsm processes
  
Actual results:
Watchdog revives vdsmd and new duplicit processes are created

Expected results:
Oprhan processes dies with it's parent or are cleaned at new vdsm start

Additional info:
gdb of one of orphan processes
pystack
/usr/share/vdsm/storage/processPool.py (124): _helperMainLoop
/usr/share/vdsm/storage/processPool.py (124): _helperMainLoop
/usr/lib64/python2.6/multiprocessing/process.py (83): run
/usr/lib64/python2.6/multiprocessing/process.py (215): _bootstrap
/usr/lib64/python2.6/multiprocessing/forking.py (89): __init__
/usr/lib64/python2.6/multiprocessing/forking.py (89): __init__
/usr/lib64/python2.6/multiprocessing/process.py (90): start
/usr/share/vdsm/storage/processPool.py (97): __init__
/usr/share/vdsm/storage/processPool.py (97): __init__
/usr/share/vdsm/storage/processPool.py (38): runExternally
/usr/share/vdsm/storage/processPool.py (38): runExternally
/usr/share/vdsm/storage/processPool.py (33): wrapper
/usr/share/vdsm/storage/processPool.py (33): wrapper
/usr/share/vdsm/storage/nfsSD.py (134): collectMetaFiles
/usr/share/vdsm/storage/nfsSD.py (134): collectMetaFiles
/usr/share/vdsm/storage/misc.py (1112): wrapper
/usr/share/vdsm/storage/misc.py (1112): wrapper
/usr/lib64/python2.6/threading.py (481): run
/usr/lib64/python2.6/threading.py (513): __bootstrap_inner
/usr/lib64/python2.6/threading.py (490): __bootstrap
/usr/lib64/python2.6/threading.py (490): __bootstrap
Comment 1 Erez Shinan 2011-05-05 09:19:47 UTC 
http://gerrit.usersys/#change,368
Comment 3 Jakub Libosvar 2011-05-18 11:34:13 UTC 
Verified vdsm-4.9-67.el6.x86_64
Comment 4 errata-xmlrpc 2011-12-06 07:14:47 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2011-1782.html
Note You need to log in before you can comment on or make changes to this bug.