Bug 167204 - lvremove eats cpu forever, holding locks, with /dev/null as stdin
Summary: lvremove eats cpu forever, holding locks, with /dev/null as stdin
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-31 15:05 UTC by Alexandre Oliva
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-08-31 19:31:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexandre Oliva 2005-08-31 15:05:51 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b3) Gecko/20050827 Fedora/1.1-0.2.8.deerpark.alpha2 Firefox/1.0+

Description of problem:
If lvremove is started from a ssh -n session, it will insist in reading a y/n response from stdin, getting read() to return 0 repeatedly.  Worse yet, it does so while holding locks, so no other lvm activity is possible.  This hit me pretty badly last night while I tried to complete some LVM rearrangements with very unreliable network access to a host.  I realize I should have used -f, but by the time I realized it, it was too late, and I couldn't even tell why my attempts to run vgreduce, pvs and lvs commands were not completing.

Version-Release number of selected component (if applicable):
lvm2-2.01.08-2.1

How reproducible:
Always

Steps to Reproduce:
1.ssh -n -f host lvremove <inactive LV>

Actual Results:  It keeps trying to read input from stdin over and over, eating cpu and holding locks.

Expected Results:  It should give up if read fails, and ideally not hold the locks while waiting for input.

Additional info:

Comment 1 Alasdair Kergon 2005-08-31 18:28:10 UTC
That's very old code - yes, it fails to do error handling properly and needs
fixing...

Comment 2 Alasdair Kergon 2005-08-31 19:31:39 UTC
fixed in CVS


Note You need to log in before you can comment on or make changes to this bug.