| Summary: | app-misc/screen hangs on reattach | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Timothy Miller <theosib> |
| Component: | Current packages | Assignee: | Sven Wegener <swegener> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | cJ-gentoo, djc, doug, dustin, EoD, gent_bz, jnerin, orzel, shell-tools |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Timothy Miller
2010-11-21 04:13:26 UTC
screen has seen a lot of development lately, so maybe the patch is in already, or the bug has been fixed in a different way. Upstream has been more responsive to its bug tracker too. This may or may not be related to the reporter's problem: I experienced this bug recently with 4.0.3-r3 when attempting to re-attach to a screen session started when running 4.0.3-r1. I reinstalled 4.0.3-r1 and was able to re-attach to running sessions. I have not upgraded and re-started my screen sessions to see if this is a bug in 4.0.3-r3. The reason that upstream wouldn't accept Hindle's patch is because it uses a longjump, and they object on philosophical grounds. Debian, on the other hand, applies the patch on practical grounds, those being that the patch actually fixes the problem. Screen devs seem to want to blame the problem on the kernel and wash their hands of it. That being said, Mr. Adamczewski has an interesting point. In my case, the lockup didn't happen in write(), which is what the patch fixes. Rather, the screen daemon was in select(), yet I couldn't attach. I don't recall whether or not I had upgraded between the time I started screen and when I tried to reattach, but I can imagine how a client/daemon protocol change (if there was any) from one version to the next could be responsible for what I experienced. If that is the case, then my problem is a non-bug, although nevertheless, Gentoo devs may want to consider applying the patch for the pre-existing hang problem. I'm seeing a similar problem, on two separate boxes (stable amd64 and stable x86). All three of those screens won't re-attach with screen-4.0.3-r4 (which has just gone stable), even though re-attaching with screen-4.0.3 (after a downgrade) works fine. One of them contains an irssi client, the others are both also doing fairly heavy networking jobs (through Python scripts, using zeromq). Please re-evaluate the merits of this bug, as this seems like a big regression. Which patch should we be looking at? I gave up researching it. http://patch-tracker.debian.org/package/screen/4.0.3-11+lenny1 (In reply to comment #3) > That being said, Mr. Adamczewski has an interesting point. In my case, the > lockup didn't happen in write(), which is what the patch fixes. Rather, the > screen daemon was in select(), yet I couldn't attach. I don't recall whether > or not I had upgraded between the time I started screen and when I tried to > reattach, but I can imagine how a client/daemon protocol change (if there was > any) from one version to the next could be responsible for what I experienced. > If that is the case, then my problem is a non-bug, although nevertheless, > Gentoo devs may want to consider applying the patch for the pre-existing hang > problem. Interesting, indeed. I've recreated the "hanging" issue quite often now, myself. However, I can easily "fix" that by killing the session and starting a new session for the task at hand. From there on out, no more hanging. While initially upset about this software issue, I have since calmed down and got my screen sessions back in order. Ergo, doubtful that I will be seeking out a patch to apply to Gentoo anymore. Without having a deeper look into the issue, I suspect that the patch 4.0.3-extend-d_termname-ng2.patch changes structures that screen uses to communicate between the backend and the attaching process and this breaks 4.0.3-r4 attaching to 4.0.3. Actually, that refers to the last user comments on the -r4 issue. Yeah, it seems I can reattach to my irssi screen fine when it's started by -r4. I guess this might not be an issue for me after all, thanks. I'm seeing this on upgrade from 4.0.3 to -r4, as well. In can confirm that exiting my screen session and re-starting with -r4 fixes it. A note about this would probably save users with long-running screen sessions a lot of searching about! I'm debating in my mind whether or not this repeated breakage is a sort of "bug" (in a work-flow sort of way). It's like breaking an API, except that the API is entirely internal to the program. Normally, no one sees these things, but in this case, there are user-visible effects. It sure would be nice if the devs would attempt to stabilize the client-server protocol so that this would happen only on major version changes. You know... a little thinking ahead, rather than lots of little tweaks. How might we get a little note about this to the developers? Timothy - sounds like something to post to screen's newsgroup or mailing list. It also sounds like something of a religious issue, so it's probably better to handle this in portage in the interm. It's worth noting that this particular breakage was caused by a patched added in portage - see comment 7. So the screen devs aren't to blame here. Just casting my vote that fixing this would be nice and what worked for me to get unstuck. The problem started after I did a normal `emerge -uD world` and detached my screen and went to bed. I woke up... but my screen session didn't. Annoying to not see the emerge output. To fix the problem I did `sudo emerge -av =app-misc/screen-4.0.3` and that allowed me to reattach to the screen session which was waiting patiently. Apparently it was upgrading to screen-4.0.3-r4 that caused the problem. (Just like the other posters indicate.) I don't know if this is practical, but it seems like screen should not upgrade if it can detect that screen is running. If it's not running, the upgrade should be fine. If the upgrade gets aborted, it could leave a message saying to shut down screen first. I could live with that; it's just the surprise of not having my session come back that was hard to take. (I had some kind of important stuff in other windows.) Thanks to all who posted and helped me solve my particular problem with this. This version of screen is no more in Portage. Some comments indicate this issue is gone with more recent versions of screen. Feel free to reopen this bug if it isn't. (In reply to Patrice Clement from comment #14) > This version of screen is no more in Portage. Some comments indicate this > issue is gone with more recent versions of screen. Feel free to reopen this > bug if it isn't. I have the issue after upgrading from app-misc/screen-4.3.1-r1 to app-misc/screen-4.4.0 . |
