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 633421 - [6.1 FEAT] Tool to safety start getty through init - inittab/startup
Summary: [6.1 FEAT] Tool to safety start getty through init - inittab/startup
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.1
Hardware: s390x
OS: All
low
urgent
Target Milestone: alpha
: 6.1
Assignee: initscripts Maintenance Team
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 538808 580566
TreeView+ depends on / blocked
 
Reported: 2010-09-13 18:12 UTC by IBM Bug Proxy
Modified: 2012-01-23 09:01 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-24 16:18:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 67052 0 None None None Never

Description IBM Bug Proxy 2010-09-13 18:12:27 UTC
1. Feature Overview:
Feature Id: [67052]
a. Name of Feature: [6.1 FEAT] Tool to safety start getty through init - inittab/startup
b. Feature Description
This feature provides a new tool: ttyrun, which safely starts getty programs and prevents re-spawns
through the init program if a terminal is not available. This is very useful when integrated in
inittab/startup since depending on your setup, Linux on System z might or might not provide a
particular terminal or console.

The tool ttyrun should be integrated per default for all possible terminal supported in a Linux on
System z environment in inittab/startup:
Notes:
??? The conmode kernel parameter selects which terminal device is available: slcp, 3215, or 3270. 
Only one terminal device ca be present at the same time.

??? Do not start a getty program on the /dev/console device!
Input and output of the /dev/console device are typically redirected to another terminal device.
This terminal device is designated as follows:
1. The last console statement on the kernel boot command line designates the preferred console.
2. The console device driver which provides the preferred console may specify a terminal device
driver for "console" input. The core TTY layer asks the console device driver to return the terminal
device driver, for instance, when reading from the /dev/console device.

Because the preferred console can be redirected to different terminal devices, starting a getty
program on the /dev/console device might cause a situation where two getty programs run on the same
terminal. In such cases, users cannot log in because both getty programs interfere with each other.

??? Linux distributions typically provide two different getty implementations: mingetty and agetty.
In contrast to mingetty, agetty provides an improved terminal device initialization and allows to
set the TERM environment variable. Using the TERM environment variable helps to preset the terminal
capabilities properly.

For more details, check section "Console device drivers" in "Device Drivers, Features, and Commands".

Example for inittab:
# Default HMC/3215/3270 console
1:2345:respawn:/sbin/ttyrun ttyS0 /sbin/mingetty --noclear %t dumb
# VT220(Linux) console:
2:2345:respawn:/sbin/ttyrun ttyS1 /sbin/mingetty --noclear %t xterm
# additional 3270 terminals:
3:2345:respawn:/sbin/ttyrun 3270/ttycons /sbin/mingetty --noclear %t dumb
# Hypervisor console(s):
h0:2345:respawn:/sbin/ttyrun hvc0 /sbin/agetty -L 9600 %t linux
h1:2345:respawn:/sbin/ttyrun hvc1 /sbin/agetty -L 9600 %t linux
h2:2345:respawn:/sbin/ttyrun hvc2 /sbin/agetty -L 9600 %t linux
h3:2345:respawn:/sbin/ttyrun hvc3 /sbin/agetty -L 9600 %t linux
h4:2345:respawn:/sbin/ttyrun hvc4 /sbin/agetty -L 9600 %t linux
h5:2345:respawn:/sbin/ttyrun hvc5 /sbin/agetty -L 9600 %t linux
h6:2345:respawn:/sbin/ttyrun hvc6 /sbin/agetty -L 9600 %t linux
h7:2345:respawn:/sbin/ttyrun hvc7 /sbin/agetty -L 9600 %t linux

Example for upstart (hvc1 use for reference, please implement startup jobs for ALL terminals as in
inittab example above!):
# hvc1 - getty
#
# This service maintains a getty on a hvc terminal device
# from the point the system is started until it is shut down again.
# If the terminal device is not available, the job exits without
# being respawned.

start on stopped rc2
start on stopped rc3
start on stopped rc4
start on started prefdm

stop  on runlevel [016]

respawn
normal exit 123
script
  /sbin/securetty hvc1

  exec /sbin/ttyrun -e 123 hvc1 /sbin/agetty -L 9600 %t xterm
end script


This feature requests the inittab/startup part. There is a dependent userspace/tool part which is
tracked by a different feature request.



2. Feature Details:
Sponsor: LTC zSeries BOE
Architectures:  zSeries - 64 native, 

Arch Specificity: purely arch specific code
Affects Kernel Modules: Field does not exist
Delivery Mechanism: LDP Deliverable
Category: other
Request Type: Installer - Enhancement from Distributor
d. Upstream Acceptance: Field does not exist
Sponsor Priority P1
f. Severity: ship issue
IBM Confidential: No
Code Contribution: 3rd party code
g. Component Version Target:---

3. Business Case
Using this tool will prevent failing re-spawns, which will avoid customer confusion and increase of
system and logging activities.

4. Primary contact at Red Hat:
John Jarvis jjarvis

5. Primary contacts at Partner:
Project Management Contact:
Hans-Georg Markgraf, mgrf.com

Technical contact(s):
Gonzalo Muelas Serrano, gmuelas.com

Comment 2 Gonzalo Muelas Serrano 2010-09-24 13:56:20 UTC
Hello John,
this feature is requesting to integrate ttyrun in an startup job.
Unfortunately through the mirroring this information got lost. I have updated
the component here directly.

Comment 3 Bill Nottingham 2010-09-24 16:18:55 UTC
This needs integrated into the core code; we do not need to ship a separate program just for handling s390 gettys. Closing RFE as WONTFIX in its current form.

Comment 4 Bill Nottingham 2010-09-24 16:23:47 UTC
Note that if you have multiple gettys on the same device due to a getting running on /dev/console... you've misconfigured your system. We don't set it up that way.
Also, passing the console type via kernel parameters is a horrible interface.

Comment 5 IBM Bug Proxy 2010-09-27 14:31:02 UTC
------- Comment From brueckner.ibm.com 2010-09-27 10:21 EDT-------
Hi Bill,

thanks for your feedback, please find my answers below.

(In reply to comment #7)
> Note that if you have multiple gettys on the same device due to a getting
> running on /dev/console... you've misconfigured your system.

That's right. But the ttyrun tool is not intented to run multiple getty programs on the same terminal.
It helps admin's to preconfigure terminal devices even if the terminals might not be
currently active. Originally, ttyrun has been developed for HVC terminal devices which can be
activated through a kernel parameter. As terminal devices are statically allocated, all terminal (minor devices) are created.

> We don't set it up that way.
Hmm.... even in RHEL5?!

> Also, passing the console type via kernel parameters is a horrible interface.

Well, that's the way it works. The last console statement designates the preferred
console which is then visible as /dev/console.   Of course, /dev/console is a associated
to a terminal devices (if the preferred console driver has one).

Comment 6 Bill Nottingham 2010-09-27 17:15:06 UTC
(In reply to comment #5)
> ------- Comment From brueckner.ibm.com 2010-09-27 10:21 EDT-------
> Hi Bill,
> 
> thanks for your feedback, please find my answers below.
> 
> (In reply to comment #7)
> > Note that if you have multiple gettys on the same device due to a getting
> > running on /dev/console... you've misconfigured your system.
> 
> That's right. But the ttyrun tool is not intented to run multiple getty
> programs on the same terminal.

No, my point is you've created a tool that appears to have a motivation of only being useful to fix a system that the admin has broken.

> > We don't set it up that way.
> Hmm.... even in RHEL5?!

We do not ever set up the machines to run gettys on both /dev/console and the backing device of /dev/console, no.

Comment 7 IBM Bug Proxy 2010-09-27 18:30:43 UTC
------- Comment From brueckner.ibm.com 2010-09-27 14:21 EDT-------
Hi Bill,

> > (In reply to comment #7)
> > > Note that if you have multiple gettys on the same device due to a getting
> > > running on /dev/console... you've misconfigured your system.
> >
> > That's right. But the ttyrun tool is not intented to run multiple getty
> > programs on the same terminal.
> No, my point is you've created a tool that appears to have a motivation of only
> being useful to fix a system that the admin has broken.

Sorry for that misunderstanding.  Let me describe it in more detail:
With RHEL6.0, we introduced a new kernel device driver for System z that
provides HVC terminal devices reusing the hypervisor console terminal
device driver.  The kernel parameter specifies the number of active HVC terminal
devices.  The point is that the tty core layer always statically allocates terminal devices,
i.e. device nodes for all 7 hvc terminal devices are created.  But only the specified
number are active.  To help admins to "safely" a getty on a hvc terminal device, ttyrun
can be used.  Later, the admin can change the kernel parameters as necessary w/o
worrying about changes in the inittab.

Another use case of ttyrun is enable and start getty programs on s390x terminals. For s390x,
availability of terminal devices depend on the environment LPAR, z/VM, etc.  So again, ttyrun
can be used to configure and start a getty program too.

Kind regards,
Hendrik

Comment 8 Bill Nottingham 2010-09-27 18:41:47 UTC
And, as I'm saying, a magic s390-only program to do this isn't practical - if the admin wants to set up additional terminal devices, they can do it via inittab as normal on all other architectures.

Comment 9 IBM Bug Proxy 2010-10-04 16:34:22 UTC
------- Comment From rsisk.com 2010-10-04 10:42 EDT-------
Code Upstream Status: No Code Required

Comment 10 IBM Bug Proxy 2010-12-13 16:12:37 UTC
------- Comment From mgrf.com 2010-12-13 11:08 EDT-------
We will request this feature for R 6.2 again - set to rejected for R 6.1

Comment 11 John Jarvis 2010-12-13 16:29:12 UTC
I think what Bill's feedback here indicates is the entire approach needs to re-thought and not just re-requested for the next release.


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