View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0009143||CentOS-6||screen||public||2015-07-28 07:28||2015-09-28 13:34|
|Summary||0009143: Screen command hangs after latest upgrade (4.0.3-18)|
|Description||I have centos-release-cr installed at my CentOS 6 IRC shell and at morning every screen was hanged.|
I notice quickly that there was update for screen (nightly installations)
Jul 28 04:34:10 Updated: screen-4.0.3-18.el6.x86_64
Downgrading older screen (4.0.3-16.el6.x86_64) fixed problem and excluded screen from yum.conf.
Also if you start screen by using newer version (4.0.3-18), then downgrading screen, it wont work anymore.
|Steps To Reproduce||- Run screen (previous version than 4.0.3-18)|
- Update screen-4.0.3-18.el6.x86_64
- Try attach (eg. screen -r)
tested with two machines, both have exactly same problem.
|Tags||No tags attached.|
The issue seems to be a difference in permissions required on /var/run/screen, the one wants 777 and the other wants 775. If an old SCREEN process runs and a new screen -r is done, it fails with the permission error but this is not printed to the terminal so it appears as hanging.
Changing the permissions on the directory doesn't work around the problem either, the new command fails with a permission error.
|This problem also happens if you have old screen session < 4.0.3-18 and you try to restore a screen session that was created == 4.0.3-18. Killing old session allowed restoring the new one|
I can confirm this unexpected behaviour :(
my current work-around:
1) yum downgrade screen && cp /usr/bin/screen /usr/bin/screen.previous && yum update screen
2) rpm2cio to extract previous /usr/bin/screen (check user/perms) and
make it available as screen.previous
-> use screen.previous to reattach the old screen session
-> use screen for the new ones