1438709 – Fix supermin init so it doesn't issue ioctl TIOCSCTTY

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1438709 - Fix supermin init so it doesn't issue ioctl TIOCSCTTY

Summary: Fix supermin init so it doesn't issue ioctl TIOCSCTTY

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	supermin
Sub Component:
Version:	7.4
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Richard W.M. Jones
QA Contact:	Virtualization Bugs
Docs Contact:
URL:
Whiteboard:
Depends On:	1484890
Blocks:	1438710
TreeView+	depends on / blocked

Reported:	2017-04-04 09:03 UTC by Richard W.M. Jones
Modified:	2018-04-10 13:47 UTC (History)
CC List:	2 users (show)
Fixed In Version:	supermin-5.1.19-1.el7
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2018-04-10 13:46:21 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHEA-2018:0792	0	None	None	None	2018-04-10 13:47:08 UTC

Description Richard W.M. Jones 2017-04-04 09:03:02 UTC

Description of problem:

The following (small) patch is required for the new virt-rescue
to work:

https://www.redhat.com/archives/libguestfs/2017-April/msg00001.html

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

supermin5-5.1.16-4.el7.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Run virt-rescue >= 1.37.

Actual results:

The bash shell in virt-rescue prints:

  bash: cannot set terminal process group (-1): Inappropriate ioctl for device
  bash: no job control in this shell

Also ^C does not work properly.

Expected results:

The message above should not be printed, and ^C should work properly
(ie. kill processes inside the virt-rescue shell, and not be ignored
or kill the whole of virt-rescue).

Comment 2 Richard W.M. Jones 2017-04-04 10:23:55 UTC

I pushed the following two commits.  Only the first one is
necessary fof fixing virt-rescue.

https://github.com/libguestfs/supermin/commit/ec0ec99d0d6efd958f51d961b4820dad75aab4ed
https://github.com/libguestfs/supermin/commit/63b21b5c66534cc85da26cb9896e57bd161f3a42

Comment 4 YongkuiGuo 2017-11-17 03:20:17 UTC

Verified with the following packages:
libguestfs-1.36.10-2.el7.x86_64
supermin5-5.1.19-1.el7.x86_64

Steps:

1. #virt-rescue --scratch
-------------------------------------------------------------
...
Welcome to virt-rescue, the libguestfs rescue shell.

Note: The contents of / (root) are the rescue appliance.
You have to mount the guest's partitions under /sysroot
before you can examine them.

><rescue> top

top - 03:03:32 up 0 min,  0 users,  load average: 0.00, 0.00, 0.00
Tasks:  50 total,   1 running,  49 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.7 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   487924 total,   444540 free,     9068 used,    34316 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   460344 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND      
  185 root      20   0   51900   1876   1400 R  1.3  0.4   0:00.04 top          
    1 root      20   0   11644   1516   1276 S  0.0  0.3   0:00.20 init         
    2 root      20   0       0      0      0 S  0.0  0.0   0:00.00 kthreadd     
    3 root      20   0       0      0      0 S  0.0  0.0   0:00.00 ksoftirqd/0  
    4 root      20   0       0      0      0 S  0.0  0.0   0:00.00 kworker/0:0  
    5 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 kworker/0:0H 
    6 root      20   0       0      0      0 S  0.0  0.0   0:00.01 kworker/u2:0 
    7 root      rt   0       0      0      0 S  0.0  0.0   0:00.00 migration/0  
    8 root      20   0       0      0      0 S  0.0  0.0   0:00.00 rcu_bh       
    9 root      20   0       0      0      0 S  0.0  0.0   0:00.06 rcu_sched    
   10 root      rt   0       0      0      0 S  0.0  0.0   0:00.00 watchdog/0   
   12 root      20   0       0      0      0 S  0.0  0.0   0:00.00 kdevtmpfs    
   13 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 netns        
   14 root      20   0       0      0      0 S  0.0  0.0   0:00.00 khungtaskd   
   15 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 writeback    
   16 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 kintegrityd  
   17 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 bioset       

><rescue> 
><rescue> exit
-------------------------------------------------------------

2. There is no error about "bash: cannot set terminal process group...". 

3. Input the top command, then ^C.  The top command exits normally. Also the whole of virt-rescue is not killed by ^C. 

So verified this bug.

Comment 7 errata-xmlrpc 2018-04-10 13:46:21 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.

https://access.redhat.com/errata/RHEA-2018:0792

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