search for: session_close_by_channel

Hi, I search in archive list if there any reason why is removed in openssh newer than 2.9.9 from function 'void session_close_by_channel(int id, void *arg)' sending of SIGTEMR and SIGHUP signals to child as was in 2.9.9 version? See follow sniped code from 2.9.9 sources: ---- openssh-2.9.9/session.c ---------------------------------------- void session_close_by_channel(int id, void *arg) ... debug("session_close_...

On Wed, May 23, 2001 at 10:49:54PM -0400, mugz wrote: > > I'm always a bit slow to report bugs i see, figuing someone else will > report it and that it will eventually get fixed. This one has been > somewhat of a problem for a while now. I run Linux Slackware -current and > just upgraded to OpenSSH 2.9p1, but I have noticed this same bug on every > platform and OS running

Hi! I am resending the following message about problems with utmp handling. * In the meantime I had some request in private mail from people asking whether I have new information. * The problem is still persistant in 2.9p2. * My own new investigations show, that the problem only appears with protocol 2, not with protocol 1, I therefore only started to note it when protocol 2 became the

...t 'int'. * entropy.c (prng_check_seedfile, prng_write_seedfile, prng_read_seedfile): Likewise. * serverloop.c (server_loop, server_loop2): Likewise. * session.c (session_dump, session_by_pid, session_exit_message, session_close_by_pid, session_have_children, session_close_by_channel): Likewise. * ssh-agent.c, sshd.c (main): Likewise. * sshpty.c (pty_setowner): Likewise. * uidswap.c: (temporarily_use_uid): Likewise. =================================================================== RCS file: authfile.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu...

...am_opie.so #6 0x0000002a957787aa in _pam_dispatch () from /lib64/libpam.so.0 #7 0x0000002a9577a182 in pam_authenticate () from /lib64/libpam.so.0 #8 0x000000552aace845 in kexgex_server () from /usr/sbin/sshd #9 0x000000552aace10b in kexgex_server () from /usr/sbin/sshd #10 0x000000552aac6404 in session_close_by_channel () from /usr/sbin/sshd #11 0x000000552aac58d2 in session_close_by_channel () from /usr/sbin/sshd #12 0x000000552aac85a5 in session_close_by_channel () from /usr/sbin/sshd #13 0x000000552aab5b39 in main () from /usr/sbin/sshd Any ideas on how this happens ? Simon -- Simon Vallet Ing?nieur Syst?...

...utput drain -> closed debug2: channel 2: rcvd close debug2: channel 2: close_read debug2: channel 2: input open -> closed debug3: channel 2: will not send data after close debug2: channel 2: almost dead debug2: channel 2: gc: notify user debug1: session_by_channel: session 0 channel 2 debug1: session_close_by_channel: channel 2 child 12289 debug1: session_close_by_channel: channel 2: has child

...ebug("session_close_by_pid: no session for pid %d", s->pid); + debug("session_close_by_pid: no session for pid %ld", (long)s->pid); return; } if (s->chanid != -1) @@ -1996,15 +1996,15 @@ channel_cancel_cleanup(s->chanid); s->chanid = -1; - debug("session_close_by_channel: channel %d kill %d", id, s->pid); + debug("session_close_by_channel: channel %d kill %ld", id, (long)s->pid); if (s->pid == 0) { /* close session immediately */ session_close(s); } else { /* notify child, delay session cleanup */ if (kill(s->pid, (s->t...

Hi, I use OpenSSH (thanks folks) to administer a mix of boxes at work and have seen some quite scary problems. I set up an ssh connection from the host to a central admin machine from a perl script running on the host. The script brings up an ssh connection to the central admin machine and sets up some reverse port redirection for administration (telnet for instance) and some forward

...xp>" Let it connect, and then hit ^C. If you look on <host>, the tail process has been orphaned, but grep, which was its parent, and a direct child of sshd, is gone. It appears that the immediate child of the sshd (grep) is sent a SIGTERM (on line 1983 of session.c, in the function session_close_by_channel()), but its child (tail) never finds out about that death, and stays happily alive. Killing the process group seems to work around the problem, but I haven't actually tried doing that in the code by negating the child's pid in the kill() statement, just killing the process group from the c...

Hi OpenSSH developers, I am using openSSH (now 2.9.9p2, but prob occurs in 2.9p2 also) to execute commands on a remote machine which outputs data to stdout then pipes it to another invocation of ssh which connects back to the first machine in the same way, where it starts a program to read and store the output from the command on the second machine. I am using the "command" option in

...BUG sshd[534]: debug2: channel 98: rcvd close May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: is dead May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: gc: notify user May 29 14:43:07 DEBUG sshd[534]: debug1: session_by_channel: session 98 channel 98 May 29 14:43:07 DEBUG sshd[534]: debug1: session_close_by_channel: channel 98 child 0 May 29 14:43:07 DEBUG sshd[534]: debug1: session_close: session 98 pid 0 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: gc: user detached May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: is dead May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: garbage collecting Ma...

...ut drain -> closed debug2: channel 1: send close debug3: channel 1: will not send data after close debug2: channel 1: rcvd close debug3: channel 1: will not send data after close debug2: channel 1: is dead debug2: channel 1: gc: notify user debug1: session_by_channel: session 1 channel 1 debug1: session_close_by_channel: channel 1 child 19952 debug1: session_close_by_channel: channel 1: has child debug2: channel 1: is dead debug2: channel 1: gc: notify user debug1: session_by_channel: session 1 channel 1 debug1: session_close_by_channel: channel 1 child 19952 debug1: session_close_by_channel: channel 1: has child...

...sion 0 req exec =================HANGS about 10 secs ===================== debug1: Received SIGCHLD. debug1: session_by_pid: pid 2652 debug1: session_exit_message: session 0 channel 0 pid 2652 debug1: session_exit_message: release channel 0 debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 child 0 debug1: session_close: session 0 pid 0 debug1: channel 0: free: server-session, nchannels 1 Connection closed by 130.35.185.57 debug1: do_cleanup Closing connection to 130.35.185.57 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are...

...debug1: channel 0: send close debug1: channel 0: full closed2 debug1: channel_free: channel 0: status: The following connections are open: #0 server-session (t4 r0 i8/0 o128/0 fd 7/7) debug1: channel_free: channel 0: dettaching channel user debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 kill 6864 debug1: Received SIGCHLD. debug1: tvp!=NULL kid 1 mili 100 error: select: Bad file descriptor debug1: session_by_pid: pid 6864 debug1: session_free: session 0 pid 6864 debug1: !channel_still_open. Closing connection to 128.2.xx.xxx debug1: compress outgoing: raw data 400, compr...

...sion 0 req exec =================HANGS about 10 secs ===================== debug1: Received SIGCHLD. debug1: session_by_pid: pid 2652 debug1: session_exit_message: session 0 channel 0 pid 2652 debug1: session_exit_message: release channel 0 debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 child 0 debug1: session_close: session 0 pid 0 debug1: channel 0: free: server-session, nchannels 1 Connection closed by 130.35.185.57 debug1: do_cleanup Closing connection to 130.35.185.57 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are...

http://bugzilla.mindrot.org/show_bug.cgi?id=1263 Summary: connection sharing often freezes Product: Portable OpenSSH Version: v4.5p1 Platform: PPC OS/Version: Mac OS X Status: NEW Severity: major Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org ReportedBy: vincent at

...+void do_authenticated(Authctxt *, const char *realname); int session_open(Authctxt*, int); - -int session_input_channel_req(Channel *, const char *); +int session_input_channel_req(Channel *, const char *, const char *realname ); void session_close_by_pid(pid_t, int); void session_close_by_channel(int, void *); void session_destroy_all(void); diff -ru openssh-3.1p1/sshd.c openssh-3.1p1-mods/sshd.c - --- openssh-3.1p1/sshd.c Thu May 9 12:18:37 2002 +++ openssh-3.1p1-mods/sshd.c Thu May 9 12:20:06 2002 @@ -1519,3 +1519,4 @@ #endif debug("KEX done"); } +...

...l 0: read<=0 rfd 7 len 0 debug2: channel 0: read failed channel 0: chan_read_failed for istate 3 debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: is dead debug2: channel 0: gc: notify user debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 child 0 debug1: session_close: session 0 pid 0 debug2: channel 0: gc: user detached debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: server-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 server-session (t...

...it_message': session.c:1896: warning: int format, pid_t arg (arg 4) session.c: In function `session_free': session.c:1937: warning: int format, pid_t arg (arg 3) session.c: In function `session_close_by_pid': session.c:1962: warning: int format, pid_t arg (arg 2) session.c: In function `session_close_by_channel': session.c:1986: warning: int format, pid_t arg (arg 3) session.c:1994: warning: int format, pid_t arg (arg 2) session.c: In function `session_proctitle': session.c:2023: warning: implicit declaration of function `setproctitle' gcc -I/opt/local/zlib-1.1.2/include -Wall -I. -I. -I/home/...

I encounter a strange problem with scp / sftp: I travel quite a bit. Normally I never have had any problems using ssh / scp / sftp to connect from my laptop to my computer at home / in the office. Currently (for the next 6 months, too long to ignore it) I'll stay in a place where scp / sftp seem to fail, while as usual I have no problems to establish an interactive ssh connection to these