Bug 180286 - LVM should still capture signals when prompting the user
LVM should still capture signals when prompting the user
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Petr Rockai
: FutureFeature
Depends On:
  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:
Last Closed: 2007-11-15 10:58:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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)
[root@link-08 tmp]#

[root@link-08 bin]# lvremove /dev/corey*
Do you really want to remove active logical volume "vol0"? [y/n]: y
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]

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.


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