Re: ssh logout hang
On Sat, Mar 19, 2005, Beni Cherniavsky wrote about Re: ssh logout hang: I'm not sure from the above description how can a subprocess still use the terminal after the shell exits - perhaps a foreground job that catches/ignores SIGHUP. I do think that I saw programs printing something after the shell has exited. A child process of the shell can definitely continue to output to the terminal after the shell exited. Try this: run sh to get a new shell, and in it run the following commands in sequence (trap '' 1; sleep 20; echo hello) disown %1 # ignore errors if this doesn't work exit The exit exits the shell, but after 20 seconds, you'll see hello printed :) By the way, in the code above, trap '' 1 ignores the SIGHUP (1) signal, and disown is needed in some shells to tell them not to kill a background process. In the original Unix implementation, not only could a process continue to generate output long after the shell that created it was gone, but this process would continue to write to the same tty device, which often meant that some other innocent user that logged on got your output to his display :) This was eventually fixed, so that when a new tty device is assigned, it cannot have any old processes still using it. I haven't followed the details on how this was done - I assume that the trick is simply to refrain from recycling the same tty device (which isn't really a device, but rather a kernel entry like /dev/tty* or /dev/pts/*) until nobody has it open. -- Nadav Har'El| Sunday, Mar 20 2005, 9 Adar II 5765 [EMAIL PROTECTED] |- Phone +972-523-790466, ICQ 13349191 |Computers are useless. They can only http://nadav.harel.org.il |give you answers. -- Pablo Picasso = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ssh logout hang
On Friday 18 March 2005 12:00, shimi wrote: Well, I see it that way: If you kill a process, all the processes that were spawned by it are being killed as well [or supposed to be]. What you just described may exist in some other operating system, but is definitely not Unix/Linux/Posix behavior. -- Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron ICQ UIN: 16527398 Linux is not portable (uses 386 task switching daetc.), and it probably never will support any thing other than AT-hard disk, as that's all I have. - Linus Torvalds, August 25, 1991. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ssh logout hang
--=-XxNlsoOqaHWSV1EEauEW Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2005-03-19 at 11:25 +0200, Oron Peled wrote: On Friday 18 March 2005 12:00, shimi wrote: Well, I see it that way: If you kill a process, all the processes that were spawned by it are being killed as well [or supposed to be]. What you just described may exist in some other operating system, but is definitely not Unix/Linux/Posix behavior. Funny, I could *swear* it happend to me in the past (like 7 years ago). (happend to me when I killed bash on a different connection, and my session died, although I was *in* a program). But I did work on many different systems back then, so, who knows :) Thanks for the heads up :) Still, why isn't that a good idea? You're leaving the program that sshd spawned (and it knows what it spawned, right?), which means you obviously want to stop ssh doing his thing for which you negotiated in the first place... I cannot see a reason to leave a stale session, which you really can't do anything with (like running 'fg' to take the process back to your control and communicate with it) ? Shimi -- --=-XxNlsoOqaHWSV1EEauEW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 TRANSITIONAL//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; CHARSET=UTF-8 META NAME=GENERATOR CONTENT=GtkHTML/3.2.5 /HEAD BODY On Sat, 2005-03-19 at 11:25 +0200, Oron Peled wrote: BLOCKQUOTE TYPE=CITE PRE FONT COLOR=#00On Friday 18 March 2005 12:00, shimi wrote:/FONT FONT COLOR=#00gt; Well, I see it that way:/FONT FONT COLOR=#00gt; /FONT FONT COLOR=#00gt; If you kill a process, all the processes that were spawned by it are/FONT FONT COLOR=#00gt; being killed as well [or supposed to be]./FONT FONT COLOR=#00What you just described may exist in some other operating/FONT FONT COLOR=#00system, but is definitely not Unix/Linux/Posix behavior./FONT /PRE /BLOCKQUOTE BR Funny, I could *swear* it happend to me in the past (like 7 years ago). (happend to me when I killed bash on a different connection, and my session died, although I was *in* a program). But I did work on many different systems back then, so, who knows :) Thanks for the heads up :)BR BR Still, why isn't that a good idea? You're leaving the program that sshd spawned (and it knows what it spawned, right?), which means you obviously want to stop ssh doing quot;his thingquot; for which you negotiated in the first place... I cannot see a reason to leave a stale session, which you really can't do anything with (like running 'fg' to take the process back to your control and communicate with it) ?BR BR ShimiBR TABLE CELLSPACING=0 CELLPADDING=0 WIDTH=100% TR TD PRE -- /PRE /TD /TR /TABLE /BODY /HTML --=-XxNlsoOqaHWSV1EEauEW-- = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ssh logout hang
On Sat, Mar 19, 2005 at 06:55:41PM +0200, shimi wrote: --=-XxNlsoOqaHWSV1EEauEW Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2005-03-19 at 11:25 +0200, Oron Peled wrote: On Friday 18 March 2005 12:00, shimi wrote: Well, I see it that way: If you kill a process, all the processes that were spawned by it are being killed as well [or supposed to be]. What you just described may exist in some other operating system, but is definitely not Unix/Linux/Posix behavior. Funny, I could *swear* it happend to me in the past (like 7 years ago). (happend to me when I killed bash on a different connection, and my session died, although I was *in* a program). But I did work on many different systems back then, so, who knows :) Thanks for the heads up :) When you destroy a terminal, every process that uses it should get SIGHUP (Hangup) on a POSIX system. This is something that should happen. There is a notion of a session and process groups. Still, why isn't that a good idea? You're leaving the program that sshd spawned (and it knows what it spawned, right?), which means you obviously want to stop ssh doing his thing for which you negotiated in the first place... I cannot see a reason to leave a stale session, which you really can't do anything with (like running 'fg' to take the process back to your control and communicate with it) ? If you kill the sshd itself you destroy the tty device. If you only kill the shell it has spawned, that shell should handle killing its children as it sees fit. I'm too lazy to check how a bash login shell handles this and how a POSIX login shell should. As for other ssh connections not via this shell (e.g: X forwarding): This is an issue for the user and the ssh client to resolve. Anyway, as any decent ssh client leaves you the option of listing the connections and terminating the whole session, you can probably live with that. -- Tzafrir Cohen | New signature for new address and | VIM is http://tzafrir.org.il | new homepage | a Mutt's [EMAIL PROTECTED] || best ICQ# 16849755 | Space reserved for other protocols | friend = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ssh logout hang
On Saturday 19 March 2005 18:55, shimi wrote: Still, why isn't that a good idea? You're leaving the program that sshd spawned (and it knows what it spawned, right?), which means you obviously want to stop ssh doing his thing for which you negotiated in the first place... I cannot see a reason to leave a stale session, which you really can't do anything with (like running 'fg' to take the process back to your control and communicate with it) ? Assume for a moment you use ssh to tunnel an X11 session or a VNC session back to your local host... Now let's reverse your question -- why should we leave a useless shell process who has already finished his duty in life (i.e: starting the said session)? Why can't sshd figure out that the tunneled file descriptors are still open (which means they are still needed)? Now guess what? The amazing thing is that sshd like any Linux process can tell when it's EOF -- and our nice daemon will kill the connection only if: - There is nothing to read from the file descriptors (EOF) - Or the client broke the connection (e.g: via ~.) Simple life. -- Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron ICQ UIN: 16527398 When you understand UNIX, you will understand the world. When you understand NTyou will understand NT - Richard Thieme = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ssh logout hang
shimi wrote: On Friday 18 March 2005 12:00, shimi wrote: If you kill a process, all the processes that were spawned by it are being killed as well [or supposed to be]. What you just described may exist in some other operating system, but is definitely not Unix/Linux/Posix behavior. Funny, I could *swear* it happend to me in the past (like 7 years ago). (happend to me when I killed bash on a different connection, and my session died, although I was *in* a program). But I did work on many different systems back then, so, who knows :) Thanks for the heads up :) There are several common reasons for whole groups of processes to die together: 1. Killing a process group: Typically a shell puts every job in a separate process group. Things like the shell command ``kill %3`` (but not ``kill 5274``) and pressing Ctrl-C at the terminal send a signal to the whole process group. This makes a lot of sense: e.g. when you kill a running make you normally want to kill any gcc it has spawned. 2. SIGHUP: usually terminates all processes attached to the terminal. * If the terminal is disconnected, the controlling process group of the terminal (normally consisting of the login shell process) get SIGHUP. A normal shell then exits, first re-sending SIGHUP to all subprocesses; a subprocess can be excluded from this re-sending by ``disown jobspec`` in bash and ``nohup command`` in tcsh. Shells by default do *not* send SIGHUP to children when exiting normally (e.g. by Ctrl-D); this can be forced by ``shopt -s hupopexit`` in bash and ``hup command`` in tsch. * When a session leader terminates for whatever reason, the forground process group gets a SIGHUP. This is probably what happened in the case you describe. * Any process surviving after the controlling process has died are called orphaned and can't access the terminal. Attempting to do so doesn't stop the process but depends on the system (SIGHUP or SIGKILL are typical). 3. SIGPIPE: a process trying to write to a pipe or FIFO that doesn't have a reading process gets a SIGPIPE (which by default kills it). This is what prevents wasted effort in commands like ``find / grep foo | head`` - when head exits, grep gets a SIGPIPE and dies, which couses find to get a SIGPIPE. If you want deeper detail, `info libc` has *very* good explanations about signal handling and job control. Still, why isn't that a good idea? You're leaving the program that sshd spawned (and it knows what it spawned, right?), which means you obviously want to stop ssh doing his thing for which you negotiated in the first place... I cannot see a reason to leave a stale session, which you really can't do anything with (like running 'fg' to take the process back to your control and communicate with it) ? How can ssh know that no children of the shell are still doing something useful to the user? They could be using the terminal or ssh's X forwarding. I'm not sure from the above description how can a subprocess still use the terminal after the shell exits - perhaps a foreground job that catches/ignores SIGHUP. I do think that I saw programs printing something after the shell has exited. Anyway, there is a point to your complaint: if the shell exits and ssh still runs, very probably only port forwarding is still used and it would be nice if ssh would background itself (*not* just exit - if port forwarding is used, you *want* ssh to keep running). The ~ escape seems to do something like this: ~ background ssh at logout when waiting for forwarded connection / X11 sessions to terminate. (from man ssh) It appears that you have to type it (after Enter) when ssh remains stuck. You might want to ask on the openssh mailing list to get more details - and a chance that your proposal of doing it automatically gets implemented. -- Beni Cherniavsky [EMAIL PROTECTED], who can only read email on weekends. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ssh logout hang
--=-6evjGHD+D17WUG/8qZfc Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-03-18 at 11:19 +0200, Ilya Konstantinov wrote: shimi wrote: Maybe try to think what programs you used when this happend (Although this is clearly a bug in sshd/ssh, and NOT in the programs. No matter what a program does, leaving a session and proper cleanup are up to the process that handles the session IMHO). It's NOT a bug in sshd. Ctrl-D is simply a way to tell your shell (which is only one of the processes using the pty which sshd allocated) to exit. If there are othere processes using that pty, they're as much of a reason to keep the SSH connection alive as your shell program was -- SSH doesn't know what's a shell and what isn't. It cannot know that, by terminating a /bin/bash process, you meant to close the entire connection. It's only by merit of the /bin/bash process being the last process to use that PTY that your connection usually closes as a result of a Ctrl-D. Well, I see it that way: If you kill a process, all the processes that were spawned by it are being killed as well [or supposed to be]. This, of course, isn't true about background processes (which is not necessarily our case). You can call it a feature, that SSH holds the pty open, but... I suspect most [all?] people would want that when the shell is closed, it will behave just like it does when you're on the local console (where the mentioned phenomenon doesn't happen, AFAIK). Since sshd is the one doing fork()/execve() for the shell, it CAN use wait(pid) (instead of checking the allocated pty pool) to see when the shell terminates, and then kill the session, IMHO. Shimi. -- shimi [EMAIL PROTECTED] --=-6evjGHD+D17WUG/8qZfc Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 TRANSITIONAL//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; CHARSET=UTF-8 META NAME=GENERATOR CONTENT=GtkHTML/3.2.5 /HEAD BODY On Fri, 2005-03-18 at 11:19 +0200, Ilya Konstantinov wrote: BLOCKQUOTE TYPE=CITE PRE FONT COLOR=#00shimi wrote:/FONT FONT COLOR=#00gt;Maybe try to think what programs you used when this happend (Although/FONT FONT COLOR=#00gt;this is clearly a bug in sshd/ssh, and NOT in the programs. No matter/FONT FONT COLOR=#00gt;what a program does, leaving a session and proper cleanup are up to the/FONT FONT COLOR=#00gt;process that handles the session IMHO)./FONT FONT COLOR=#00gt;/FONT FONT COLOR=#00It's NOT a bug in sshd. Ctrl-D is simply a way to tell your shell (which /FONT FONT COLOR=#00is only one of the processes using the pty which sshd allocated) to /FONT FONT COLOR=#00exit. If there are othere processes using that pty, they're as much of a /FONT FONT COLOR=#00reason to keep the SSH connection alive as your shell program was -- SSH /FONT FONT COLOR=#00doesn't know what's a shell and what isn't. It cannot know that, by /FONT FONT COLOR=#00terminating a /bin/bash process, you meant to close the entire connection./FONT FONT COLOR=#00It's only by merit of the /bin/bash process being the last process to /FONT FONT COLOR=#00use that PTY that your connection usually closes as a result of a Ctrl-D./FONT /PRE /BLOCKQUOTE BR Well, I see it that way:BR BR If you kill a process, all the processes that were spawned by it are being killed as well [or supposed to be]. This, of course, isn't true about background processes (which is not necessarily our case). You can call it a feature, that SSH holds the pty open, but... I suspect most [all?] people would want that when the shell is closed, it will behave just like it does when you're on the local console (where the mentioned phenomenon doesn't happen, AFAIK). Since sshd is the one doing fork()/execve() for the shell, it CAN use wait(pid) (instead of checking the allocated pty pool) to see when the shell terminates, and then kill the session, IMHO.BR BR Shimi.BR BR TABLE CELLSPACING=0 CELLPADDING=0 WIDTH=100% TR TD -- BR shimi lt;A HREF=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/Agt; /TD /TR /TABLE /BODY /HTML --=-6evjGHD+D17WUG/8qZfc-- = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ssh logout hang
shimi wrote: Maybe try to think what programs you used when this happend (Although this is clearly a bug in sshd/ssh, and NOT in the programs. No matter what a program does, leaving a session and proper cleanup are up to the process that handles the session IMHO). It's NOT a bug in sshd. Ctrl-D is simply a way to tell your shell (which is only one of the processes using the pty which sshd allocated) to exit. If there are othere processes using that pty, they're as much of a reason to keep the SSH connection alive as your shell program was -- SSH doesn't know what's a shell and what isn't. It cannot know that, by terminating a /bin/bash process, you meant to close the entire connection. It's only by merit of the /bin/bash process being the last process to use that PTY that your connection usually closes as a result of a Ctrl-D. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
ssh logout hang
I'm sure some of you have seen this: ssh session hangs/freezes on logout: you hit Ctrl-D, cursor instead of releasing the parent shell jumps to a new line and just sits there. googling on 'ssh logout freeze OR hang' reveals a plethora of evidence that the problem I'm having here is not an isolated case. Some people suggest that the hang occures because of the unfinished background jobs. That's not my case however. To make things worse it happens at random with different combinations of *NIX/SSH. Any insights? -- Warm regards, Michael Green *^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^* Assistant Unix Admin Division of Information Systems Weizmann Institute of Science Rechovot 76100, Israel Tel.: 972-8-9344216 Fax.: 972-8-9344102 Cel.: 972-52-3638926 *^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^* = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ssh logout hang
Michael Green wrote: I'm sure some of you have seen this: ssh session hangs/freezes on logout: you hit Ctrl-D, cursor instead of releasing the parent shell jumps to a new line and just sits there. googling on 'ssh logout freeze OR hang' reveals a plethora of evidence that the problem I'm having here is not an isolated case. Some people suggest that the hang occures because of the unfinished background jobs. That's not my case however. To make things worse it happens at random with different combinations of *NIX/SSH. Any insights? Sometimes it happens because there is some TCP forwarding going on. I don't know whether that can account to 100% of the cases, but at least in some of the cases this is it. To solve it, use the SSH escape sequence to terminate ssh. Just press Enter, followed by ~ and . You can also do ~ to put ssh into the background. ~? will give you a list of commands you can issue. Take note, however, that the ~ escape only works if it's the first character typed on the line. This is the reason I said you should press enter before you type it. Hope this helps, Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ssh logout hang
--=-cQ8Fz5lHzI/nfX+UZCi8 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-03-17 at 12:12 +0200, Michael Green wrote: I'm sure some of you have seen this: ssh session hangs/freezes on logout: you hit Ctrl-D, cursor instead of releasing the parent shell jumps to a new line and just sits there. googling on 'ssh logout freeze OR hang' reveals a plethora of evidence that the problem I'm having here is not an isolated case. Some people suggest that the hang occures because of the unfinished background jobs. That's not my case however. To make things worse it happens at random with different combinations of *NIX/SSH. Any insights? Indeed, that happens with unfinished background jobs (happens to me all the time), but I do not consider the background-ness of the jobs is indeed the cause. I did not dig deeply into this, but I came to the conclusion, that processes that you ran during the session took control (if you can call it so...) over the pts you're using. Something like an unflushed buffer or something. And SSH, when it quits, tries to flush whatever that thing is, without success of course (as the job has already exited). I know it's not much but maybe it can help you in some way (I just go to the other console and killall -9 ssh :)) Maybe try to think what programs you used when this happend (Although this is clearly a bug in sshd/ssh, and NOT in the programs. No matter what a program does, leaving a session and proper cleanup are up to the process that handles the session IMHO). -- shimi [EMAIL PROTECTED] --=-cQ8Fz5lHzI/nfX+UZCi8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 TRANSITIONAL//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; CHARSET=UTF-8 META NAME=GENERATOR CONTENT=GtkHTML/3.2.5 /HEAD BODY On Thu, 2005-03-17 at 12:12 +0200, Michael Green wrote: BLOCKQUOTE TYPE=CITE PRE FONT COLOR=#00I'm sure some of you have seen this:/FONT FONT COLOR=#00ssh session hangs/freezes on logout: you hit Ctrl-D, cursor instead of/FONT FONT COLOR=#00releasing the parent shell jumps to a new line and just sits there./FONT FONT COLOR=#00googling on 'ssh logout freeze OR hang' reveals a plethora of evidence/FONT FONT COLOR=#00that the problem I'm having here is not an isolated case. Some people/FONT FONT COLOR=#00suggest that the hang occures because of the unfinished background/FONT FONT COLOR=#00jobs. That's not my case however./FONT FONT COLOR=#00To make things worse it happens at random with different combinations/FONT FONT COLOR=#00of *NIX/SSH./FONT FONT COLOR=#00Any insights?/FONT /PRE /BLOCKQUOTE BR Indeed, that happens with unfinished background jobs (happens to me all the time), but I do not consider the background-ness of the jobs is indeed the cause. I did not dig deeply into this, but I came to the conclusion, that processes that you ran during the session took quot;controlquot; (if you can call it so...) over the pts you're using. Something like an unflushed buffer or something. And SSH, when it quits, tries to flush whatever that thing is, without success of course (as the job has already exited).BR BR I know it's not much but maybe it can help you in some way (I just go to the other console and killall -9 ssh :))BR BR Maybe try to think what programs you used when this happend (Although this is clearly a bug in sshd/ssh, and NOT in the programs. No matter what a program does, leaving a session and proper cleanup are up to the process that handles the session IMHO).BR BR TABLE CELLSPACING=0 CELLPADDING=0 WIDTH=100% TR TD -- BR shimi lt;A HREF=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/Agt; /TD /TR /TABLE /BODY /HTML --=-cQ8Fz5lHzI/nfX+UZCi8-- = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ssh logout hang
Michael Green wrote: I'm sure some of you have seen this: ssh session hangs/freezes on logout: you hit Ctrl-D, cursor instead of releasing the parent shell jumps to a new line and just sits there. googling on 'ssh logout freeze OR hang' reveals a plethora of evidence that the problem I'm having here is not an isolated case. Some people suggest that the hang occures because of the unfinished background jobs. That's not my case however. To make things worse it happens at random with different combinations of *NIX/SSH. Any insights? From my experience it is almost always to do with background tasks or open tunnels that the SSH session is forwarding- for example, by default it connects with X forwarding and that may keep the shell from logging out. Try disabling X forwarding as a test. Cheers, -David
Re: ssh logout hang
On Thursday 17 March 2005 12:12, Michael Green wrote: I'm sure some of you have seen this: ssh session hangs/freezes on logout: you hit Ctrl-D, cursor instead of releasing the parent shell jumps to a new line and just sits there. If the client side does not have a bug, you can always shutdown the connection by using ~. (that's Tilde-dot, just like in bad-old rlogin). ... Some people suggest that the hang occures because of the unfinished background jobs. They are right! Here is brute force way to confirm this: - Log on to the same machine (from a different terminal). - Find all your processes (ps auxw). - Kill them one by one. - See when your hanged ssh is released. It is easy to miss background processes (especially with X forwarding) that leaves stdin/stdout/stderr opened and thus cause sshd not to close its side of the connection. I'll give you a concrete example. I use gpg-agent (to help manage mail signatures etc.) This program daemonize itself and provide gpg password caching service over local socket. The problem was, that it reports the socket name to stdout (to be used by shell scripts: eval `gpg-agent `) and fails to close stdout/stdin/stderr afterwords. Cheers, -- Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron ICQ UIN: 16527398 But it does move! -- Galileo Galilei = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ssh logout hang
On Thu, Mar 17, 2005 at 12:12:50PM +0200, Michael Green wrote: I'm sure some of you have seen this: ssh session hangs/freezes on logout: you hit Ctrl-D, cursor instead of releasing the parent shell jumps to a new line and just sits there. googling on 'ssh logout freeze OR hang' reveals a plethora of evidence that the problem I'm having here is not an isolated case. Some people suggest that the hang occures because of the unfinished background jobs. That's not my case however. To make things worse it happens at random with different combinations of *NIX/SSH. An ssh connection (session) can multiplex a number of ssh connections. To see a list of such connections for your current session, press '~#' in a new line, that is: Enter, '~', shift-`, shift-3. To disconnect, use ~. instead of ~# . To see a full list of commands: ~? . Note that this is implemented by the ssh client that you use. The above are from openssh. ssh.com's ssh client has something similar. If there are some existing connections (e.g: forwarded X windows) the session won't be terminated and the tcp connection won't break. You can always break it the hard way using ~. . -- Tzafrir Cohen | New signature for new address and | VIM is http://tzafrir.org.il | new homepage | a Mutt's [EMAIL PROTECTED] || best ICQ# 16849755 | Space reserved for other protocols | friend = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ssh logout hang
You might be running some background process that doesn't detach from the tty. (In that case SSH is waiting for the process to exit) Gilboa On Thu, 2005-03-17 at 12:12 +0200, Michael Green wrote: I'm sure some of you have seen this: ssh session hangs/freezes on logout: you hit Ctrl-D, cursor instead of releasing the parent shell jumps to a new line and just sits there. googling on 'ssh logout freeze OR hang' reveals a plethora of evidence that the problem I'm having here is not an isolated case. Some people suggest that the hang occures because of the unfinished background jobs. That's not my case however. To make things worse it happens at random with different combinations of *NIX/SSH. -- Gilboa Davara [EMAIL PROTECTED] Nice Systems
