LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   [BUG] "screen" will not exit unless ^Z (http://www.linuxquestions.org/questions/slackware-14/%5Bbug%5D-screen-will-not-exit-unless-%5Ez-4175479336/)

guanx 10-02-2013 10:23 AM

[BUG] "screen" will not exit unless ^Z
 
2 Attachment(s)
Update: Downgraded NVIDIA driver from 319.60 to 319.49 and the problem disappeared.

Hello,

I am running slackware-current (not slackware64-current, not slackwarearm-current, etc.) mirrored from ftp.slackware.com today.

When I start "screen" in an X terminal emulator, e.g. konsole or xterm, then press ^d or type "exit" to end the screen session, or detach from the session with "^a d", screen prints "[screen is terminating]" but I cannot go back to the shell prompt unless pressing ^Z (^C does not work).

There is no such problem in text tty. Only in X terminal emulators.

A recording is attached
Code:

chmod +x bbsplay.txt
./bbsplay.txt screen.log

Any idea? Thanks!

willysr 10-02-2013 10:59 AM

i also have a -current machine and it's working fine here
tried ^d and ^a d and both are working

guanx 10-07-2013 06:27 AM

[removed]

guanx 10-07-2013 11:27 AM

Strace shows that when this problem occurs, screen receives no SIGHUP which it ought to receive. The following patch fixes it but the origin of the bug is unknown to me
Code:

diff -ru screen-4.0.3.orig/screen.c screen-4.0.3/screen.c
--- screen-4.0.3.orig/screen.c  2003-09-08 16:26:41.000000000 +0200
+++ screen-4.0.3/screen.c      2013-10-07 17:15:07.068676486 +0200
@@ -360,14 +360,11 @@
 #if (defined(AUX) || defined(_AUX_SOURCE)) && defined(POSIX)
  setcompat(COMPAT_POSIX|COMPAT_BSDPROT); /* turn on seteuid support */
 #endif
-#if defined(sun) && defined(SVR4)
  {
-    /* Solaris' login blocks SIGHUP! This is _very bad_ */
    sigset_t sset;
    sigemptyset(&sset);
    sigprocmask(SIG_SETMASK, &sset, 0);
  }
-#endif
 
  /*
    *  First, close all unused descriptors

I am terrified by the coding style of screen. I see obvious use-after-free sometimes. The K&R manner gives me an impression that debugging this program is beyond my ability. So ... I don't know how I fixed it, nor will I know in the future.

GazL 10-07-2013 11:55 AM

"screen" does have somewhat of a reputation for dodgy code. Have you considered using tmux instead?

guanx 10-07-2013 12:03 PM

Quote:

Originally Posted by GazL (Post 5041558)
"screen" does have somewhat of a reputation for dodgy code. Have you considered using tmux instead?

Not yet, because screen is more widely installed and I see no strong reason to learn a new thing when the old suffices.

volkerdi 10-07-2013 08:39 PM

This patch doesn't look correct to me, and this part of the code is unchanged in git. Unless the problem with the code (and the fix) can be adequately explained I'm not going to apply this patch.

Besides that, screen is exiting correctly here on my -current machines in all of the terminal emulators that I tested. Not sure what could be different on your machine.

Thom1b 10-08-2013 12:49 AM

Quote:

Originally Posted by guanx (Post 5041563)
Not yet, because screen is more widely installed and I see no strong reason to learn a new thing when the old suffices.

A good reason is the old is very buggy and doesn't seem maintain. I switched from screen to tmux (maybe two years ago) because of bugs, and I'm very happy with tmux.

guanx 10-08-2013 05:20 AM

Quote:

Originally Posted by volkerdi (Post 5041784)
This patch doesn't look correct to me, and this part of the code is unchanged in git. Unless the problem with the code (and the fix) can be adequately explained I'm not going to apply this patch.

Besides that, screen is exiting correctly here on my -current machines in all of the terminal emulators that I tested. Not sure what could be different on your machine.

I find some bug reports which are probably related to this error:
http://lists.kde.org/?l=kde-core-dev...6773523973&w=4
http://lists.opensuse.org/opensuse-b.../msg05412.html
It looks very much like KDE should be fixed also, because sometimes I get SIGINT blocked upon KDE start, instead of SIGHUP. This is fatal because I use SIGINT much more often (Ctrl-C doesn't work). I confirmed by logging on and off to/from KDE in runlevel 4, and running this simple program:
Code:

$ cat siggetmask.c
#include <signal.h>

int main()
{
    return siggetmask();
}
$ make siggetmask
cc    siggetmask.c  -o siggetmask
siggetmask.c: In function ‘main’:
siggetmask.c:5:5: warning: ‘siggetmask’ is deprecated (declared at /usr/include/signal.h:203) [-Wdeprecated-declarations]
    return siggetmask();
    ^
$ ./siggetmask; echo $?
1 # sometimes it's 2, but in most cases 1
$

Anyway, because screen must use SIGHUP, it is good practice to ensure it unblocked. This patch above doesn't harm. Does it? I'm novice on signals. Please do point out if I'm wrong. Thanks!

guanx 10-08-2013 05:29 AM

Quote:

Originally Posted by Thom1b (Post 5041866)
A good reason is the old is very buggy and doesn't seem maintain. I switched from screen to tmux (maybe two years ago) because of bugs, and I'm very happy with tmux.

I'd be very happy to use tmux but most of the computers I use don't have it pre-installed. I can only find screen. And I don't have admin privilege on 1/3 of them. It's overkill to install tmux in my $HOME every time I touch a new computer.

Another reason to stay with screen is that when my colleagues ask me how to do something I can simply sent them the screen command, without asking them to install tmux first. Installing something seems more intrusive than running a well known command.

Thom1b 10-08-2013 05:36 AM

Quote:

Originally Posted by guanx (Post 5041999)
I'd be very happy to use tmux but most of the computers I use don't have it pre-installed. I can only find screen. And I don't have admin privilege on 1/3 of them. It's overkill to install tmux in my $HOME every time I touch a new computer.

You're right, this is a good reason to stay with screen.

Quote:

Originally Posted by guanx (Post 5041999)
Another reason to stay with screen is that when my colleagues ask me how to do something I can simply sent them the screen command, without asking them to install tmux first. Installing something seems more intrusive than running a well known command.

Now tmux is available in many distribution, maybe it's a good idea to suggest Pat to include tmux in slackware. :)

guanx 10-08-2013 07:07 AM

Downgraded NVIDIA driver from 319.60 to 319.49 and the problem disappeared. If the error comes again I will update this thread.

phenixia2003 10-08-2013 12:01 PM

Hello,

I looked at this and experienced the same issue on slackware64-current (beta from sept 18) with nvidia 319.60, but only when screen is started from konsole. There's no problem when screen is started from uxterm, xterm, terminal.

Downgrading nvidia to 319.49 solves the problem.

I reinstalled nvidia 319.60, and, started Xfce. I tried screen inside konsole, and there's no issue. I returned to Kde, started screen inside konsole, and I encountered the issue again.

I also tried on slackware 14.0 with nvidia 319.60 and didn't experienced this issue.

--
SeB

guanx 10-08-2013 12:53 PM

Hi phenixia2003,

Thanks for your very clear description of your test result. I made a mistake in my previous tests by sometimes starting xterm/rxvt from konsole, then they inherited the signal mask of konsole.

My test result with slackware-current + NVIDIA 319.60 / 319.49 is identical to your result with slackware64-current.

bosth 01-04-2014 01:23 AM

I ran into this same issue as well. Disabling most Desktop Effects fixed it for me (not sure exactly which one).

slackware64-current, KDE 4.12, NVIDIA 331.20

The issue is back. Switching to tmux.


All times are GMT -5. The time now is 09:02 AM.