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 601674 - [abrt] crash in mingetty-1.08-4.1.el6: Process /sbin/mingetty was killed by signal 3 (SIGQUIT)
Summary: [abrt] crash in mingetty-1.08-4.1.el6: Process /sbin/mingetty was killed by s...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: mingetty
Version: 6.0
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Petr Pisar
QA Contact: qe-baseos-daemons
URL:
Whiteboard: abrt_hash:11c13030243e0530e6896a8d9b4...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-08 12:48 UTC by Gordan Bobic
Modified: 2015-11-23 14:42 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-27 11:15:02 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
File: backtrace (3.30 KB, text/plain)
2010-06-08 12:48 UTC, Gordan Bobic
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 601733 0 low CLOSED X/getty race condition causes 100% CPU usage 2021-02-22 00:41:40 UTC

Description Gordan Bobic 2010-06-08 12:48:08 UTC
abrt 1.0.7 detected a crash.

architecture: x86_64
Attached file: backtrace
cmdline: /sbin/mingetty --noclear /dev/tty6
comment: The only thing that springs to mind is that I have added "--noclear" option to init's tty startup script, but I doubt that's the cause.
component: mingetty
executable: /sbin/mingetty
kernel: 2.6.32-19.el6.x86_64
package: mingetty-1.08-4.1.el6
rating: 4
reason: Process /sbin/mingetty was killed by signal 3 (SIGQUIT)
release: Red Hat Enterprise Linux release 6.0 Beta (Santiago)
How to reproduce: No manual intervention, this runs from init.

Comment 1 Gordan Bobic 2010-06-08 12:48:12 UTC
Created attachment 422178 [details]
File: backtrace

Comment 3 RHEL Program Management 2010-06-08 13:13:31 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 4 Ondrej Vasik 2010-06-24 14:40:22 UTC
As there is no clear reproducer and nothing obvious in the backtrace/related sourcecode, there is not much to do with it at the moment. Please add some hints how to reproduce it (if you still experience the issue, maybe some configuration details could help).

Comment 5 Gordan Bobic 2010-06-24 14:59:08 UTC
It appears to be related to this bug, the two problems always arise together:
https://bugzilla.redhat.com/show_bug.cgi?id=601733

Comment 6 Roman Rakus 2010-06-24 15:14:06 UTC
I guess this will be somehow related to configuration of /dev/ttyN devices.

Comment 7 Gordan Bobic 2010-06-24 15:35:34 UTC
Not sure. I'll put RHEL6b on another machine in the next few days and check if it is reproducible there. I suspect it will be, because I had a similar symptom (extreme Xorg CPU usage) on another machine previously. Unfortunately, I repurposed it before I could get to the bottom of what was causing it.

Comment 8 Petr Pisar 2010-07-20 09:11:47 UTC
Mingetty dies on SIGQUIT. There is no such signal emitted by mingetty. Mingetty ignores SIGHUP while opening TTY only. The signal has been received in read(0,...) while reading log-in name.

I guess somebody kills (by SIGQUIT) mingetty from outside. init or kdm via ConsoleKit probably.

Default action assigned to SIGQUIT is to core dump that triggers abrt. I can change the code to terminate in other way not to provoke abrt. However better way would be if culprit sent SIGTERM instead of SIGQUIT.

Comment 9 Gordan Bobic 2010-07-20 09:29:56 UTC
I'm reasonably confident that this is actually the same issue as this one:
https://bugzilla.redhat.com/show_bug.cgi?id=601733
which would make it a KDM bug, and a serious one.

Unfortunately, the linked bug was downgraded to low priority even though it makes KDE completely unusable on a single-core machine, not to mention that it also makes it completely unusable on any laptop where non-mains powered operation is required. (100% CPU usage all the time is not good for battery life)

KDM clashes with mingetty over which terminals it runs on because it for some reason ignores the settings regarding which terminal X should run on.

Comment 11 RHEL Program Management 2011-04-27 11:15:02 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Comment 12 Huzaifa S. Sidhpurwala 2015-11-23 08:34:39 UTC
Due to a bug in the ABRT reporting tool, this bug report may have contained information that you did not intend to include.  As a precaution, we have made the bug report private.  You may wish to review the bug report in an effort to identify information that you inadvertently included in the bug report and take appropriate remedial action.

Comment 13 Petr Pisar 2015-11-23 14:42:14 UTC
I could not find any sensitive data specific for the host or an user. Thus I'm making the report public again.


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