Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionJaroslav Škarvada
2016-03-07 13:48:38 UTC
Description of problem:
It seems that the screen update between RHEL-7.1 - RHEL-7.2 broke the screen protocol. This can cause serious trouble to customers/users. Imagine scenarios where there are long term running processes in screens. By performing the screen update, these screens are no longer accessible and the processes running there are inaccessible.
What worse, the screen client hangs upon attempt to connect to the screen server and it is not possible to terminate it (i.e. it doesn't respond to CTRL+C). The only way how to terminate it is to login via another shell and kill the processes by hand.
This causes really bad user experience and can cause serious harm. What worse, only the release from the NVR was bumped which doesn't signal that the update uses incompatible protocol. Not counting the scenarios where the update process is initiated from the screen itself and user disconnects from the screen during the update.
Version-Release number of selected component (if applicable):
screen-4.1.0-0.19.20120314git3c2946.el7.x86_64
How reproducible:
Always
Steps to Reproduce:
1. install screen-4.1.0-0.19.20120314git3c2946.el7.x86_64
2. screen
3. disconnect from screen
4. update to screen-4.1.0-0.21.20120314git3c2946.el7.x86_64
5. screen -r
Actual results:
screen client hangs, screen server not accessible
Expected results:
screen session reconnected
Additional info:
I guess the protocol was broken by some backport. I think we should provide specific screen protocols downstream hacks, to make new screen clients backward compatible to the older server.
Comment 1Jaroslav Škarvada
2016-03-07 13:49:30 UTC
Screen downgrade make the running screens again accessible.
Comment 3Jaroslav Škarvada
2016-03-07 16:56:44 UTC
Probably dupe of bug 1253697, maybe fixed by screen-4.1.0-0.22.20120314git3c2946.el7, but I haven't checked it.
I have check this issue in RHEL-7.3 with screen package in the latest version in RHEL (screen-4.1.0-0.23.20120314git3c2946.el7_2).
This issue is not presented here. It looks like it was solved in bugzilla #1253697. This solution is already presented in RHEL-7.3 branch.
Because of this, I am closing this bugzilla as DUPLICATED of 1253697.
Feel free to reopen it in case you think, that described issue still persist.
*** This bug has been marked as a duplicate of bug 1253697 ***