Bug 180286 - LVM should still capture signals when prompting the user
LVM should still capture signals when prompting the user
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
4.0
All Linux
low Severity medium
: ---
: ---
Assigned To: Petr Rockai
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-06 16:44 EST by Corey Marthaler
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2007-0753
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-15 10:58:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lvm2-prompt-sigint.diff (2.58 KB, patch)
2007-05-23 12:57 EDT, Petr Rockai
no flags Details | Diff

  None (edit)
Description Corey Marthaler 2006-02-06 16:44:33 EST
Description of problem:
I have 200 LVs and accidently tried to remove them without the "-f" flag. This
results in a prompt for every LV and I just have the time to type "y" 200 times.
Other cmds capture signals when prompting, so lvm should as well.

[root@link-08 tmp]# ls [tab]
Display all 161 possibilities? (y or n)
[Ctrl-C]
[root@link-08 tmp]#

[root@link-08 bin]# lvremove /dev/corey*
Do you really want to remove active logical volume "vol0"? [y/n]: y
[Ctrl-C]
Comment 1 Alasdair Kergon 2006-02-10 14:32:38 EST
Yeah - not sure how easy it'll be to do this though because of the way the code
is structured.   [Blocked ctrl-c means a lock is held on the VG; so we have to
release that lock while asking the question - then get the lock again and go
back to square one and revalidate everything.  Alternatively have to find a way
to decouple ctrl-c and the locking safely.]
Comment 7 RHEL Product and Program Management 2007-03-09 20:09:51 EST
This bugzilla had previously been approved for engineering
consideration but Red Hat Product Management is currently reevaluating
this issue for inclusion in RHEL4.6.
Comment 8 Alasdair Kergon 2007-05-16 10:35:49 EDT
Suggest investigating the 2nd option first: yes_no_prompt() calls new function
in locking.c that installs a ctrl-c handler iff _signals_blocked, and if
triggered, yes_no_prompt() returns \0 for caller to check for and abort.
Comment 9 Alasdair Kergon 2007-05-16 10:44:50 EDT
(c.f. existing ctrl-c handler code in file_locking.c used when waiting for a lock)
Comment 11 Petr Rockai 2007-05-23 12:57:21 EDT
Created attachment 155274 [details]
lvm2-prompt-sigint.diff

A slightly different approach, where yes_no_prompt itself reacts to the signal.
I think yes_no_prompt should not be called in the middle of "critical" region
of code, so it should be safe this way (need to verify and document that
yes_no_prompt is a point of possible interruption, i suppose). It should
however be easy to lift the sigint_allow/sigint_check_exit/sigint_restore calls
into callers of yes_no_prompt, either way. (Looking at the patch,
sigint_check_exit() call could be added to sigint_restore(), although i'm not
sure how good idea that is. Just a sidenote.)
Comment 14 Corey Marthaler 2007-07-27 11:42:30 EDT
fix verified in lvm2-2.02.27-1.el4.
Comment 16 errata-xmlrpc 2007-11-15 10:58:12 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0753.html

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