Re: more strange problem with broken pipes and ssh
In message [EMAIL PROTECTED], Mike Tancsa write s: At 07:18 PM 3/3/2001 -0800, Don Lewis wrote: I wonder if this problem might be shell dependent. Maybe some shells reset SIGPIPE to SIG_DFL and some don't modify whatever they inherit. I'm seeing the problem with csh. What shells are everyone else running? /bin/tcsh /bin/sh /bin/csh give me the same results. What about the grep | less example ? Can you reproduce that ? with bash, the result is a little different. On the maillog example, I only get one "broken pipe" at the end. I've tried it with bash, sh, and tcsh. I can't seem to get a SIGPIPE. Regards, Phone: (250)387-8437 Cy SchubertFax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: [EMAIL PROTECTED] Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: more strange problem with broken pipes and ssh
On Mar 3, 10:35pm, Mike Tancsa wrote:
} Subject: Re: more strange problem with broken pipes and ssh
} At 07:18 PM 3/3/2001 -0800, Don Lewis wrote:
} I believe the fix is to call "signal(SIGPIPE, SIG_DFL)" in do_exec_pty()
} in session.c.
}
} Well, I just popped this in the function, and it worked! Thank you very
} much for validating and fixing this most annoying problem!
}
} ---Mike
I'm also wondering of the signal(SIGPIPE, SIG_DFL) in do_exec_no_pty(),
which is a FreeBSD addition, might be misplaced. I think it shouldn't
be called until after the fork(). Here's a slightly different patch
which removes the signal() call from do_exec_no_pty() and adds it to
do_child(), which handles the child process for both do_exec_no_pty()
and do_exec_pty().
Index: crypto/openssh/session.c
===
RCS file: /home/ncvs/src/crypto/openssh/session.c,v
retrieving revision 1.4.2.7
diff -u -u -r1.4.2.7 session.c
--- crypto/openssh/session.c2001/02/04 20:21:06 1.4.2.7
+++ crypto/openssh/session.c2001/03/04 03:36:26
@@ -448,8 +448,6 @@
if (s == NULL)
fatal("do_exec_no_pty: no session");
- signal(SIGPIPE, SIG_DFL);
-
session_proctitle(s);
#ifdef USE_PAM
@@ -972,6 +970,9 @@
extern char **environ;
struct stat st;
char *argv[10];
+
+ /* Allow the child processes to receive SIGPIPE */
+ signal(SIGPIPE, SIG_DFL);
/* login(1) is only called if we execute the login shell */
if (options.use_login command != NULL)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: more strange problem with broken pipes and ssh
At 07:54 PM 3/3/2001 -0800, Don Lewis wrote: I use /bin/csh here. I can't reproduce this problem with the grep | less example after I made the patch :-) Nor I :-) Thanks very much again for fixing this! The problem was quite annoying. I will install the patch on a number of servers here so that it can get tested a bit! ---Mike Mike Tancsa, tel +1 519 651 3400 Network Administration, [EMAIL PROTECTED] Sentex Communications www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: more strange problem with broken pipes and ssh
Mike Tancsa wrote: At 06:32 AM 3/2/01 -0800, Cy Schubert - ITSD Open Systems Group wrote: In message [EMAIL PROTECTED], Mike Tancsa wr ites: OK, here is another strange problem with SSH and pipes. When connecting via some means other than ssh, the commands grep reject /var/log/maillog | less displays data as expected. However, when connected via ssh, hitting q to exit from less, I get a whole mess of grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe This is with stable as of today and the problem showed up since the last ssh commits. The amount of broken pipes seems to scale with the amount of data less has, and it seems you need at least more than a screen full. I'm using -stable as of Feb 27 04:15 PST. No problems here. Is there something in your ssh config that might either cause this bug to manifest itself? If I recall you never had the problem with the makewhatis script and ssh as well due to some special config of your ssh (Kerberos?) ? This is with 4.2-STABLE FreeBSD 4.2-STABLE #0: Mon Feb 26 Like the problem with the makewhatis broken pipes (and certain ports), the problem does not show itself when connecting to the machine via telnet or rlogin. I had some broken pipe messages when I tried to upgrade to kde-2.1. I backed up and telneted in and finished the install. Kent ---Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
