Re: strange grep or tail behaviour
Replying to my own message... I should have looked in the Unix FAQ first :) I believe the answer was in 3.14. It has to do with the amount of buffering. http://www.faqs.org/faqs/unix-faq/faq/part3/section-14.html I did receive some off-list emails about this. One used strace to see that it was buffered. (Thank you.) Another simply said "man tail" -- well I already read the manpage and info page for it; I must have missed something; please share specific details. I guess as a workaround I could just use a single instance of awk, sed, grep, perl or a simple bash script to solve my problem. Or I could find and modify a BSD-licensed grep to not buffer the output. Does anyone know of a grep that can use multiple expressions that some are reversed, for example, one grep that can do the same as "grep keyword | grep -v exclude" (without knowing the placement of the keywords in the line)? Or can anyone share some examples of using awk to do this? Jeremy C. Reed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Performance monitor
On Tue, May 01, 2001 at 07:30:44PM +0200, Marcin Owsiany wrote: > I wonder what you guys use as performance monitoring/bottleneck > detection software (preferably for a text terminal)? I mean I > would like to see some more detailed data than just 'load > average' :-) I don't know the LPP (I think) that was mentioned before, but you should also look into using sar (System Accounting and Reporting) It's a (relatively) standard Unix tool for this sort of thing. HP has it standard on HPUX, and I know there is a free Linux version made by someone from 'At-Computing'. It's called atsar I don't know if it's packaged, I think so. Otherwise a search on freshmeat would turn it up. If that fails try contacting At on: www.atcomputing.nl (Even though their company is a direct competitor to mine ;) ) Mark Janssen Unix Consultant @ SyConOS IT E-mail: [EMAIL PROTECTED]GnuPG Key Id: 357D2178 http: markjanssen.homeip.net and markjanssen.[com|net|org|nl] Fax/VoiceMail: +31 84 8757555 Finger for GPG and GeekCode
Re: Performance monitor
On Tue, May 01, 2001 at 07:30:44PM +0200, Marcin Owsiany wrote: > I wonder what you guys use as performance monitoring/bottleneck > detection software (preferably for a text terminal)? I mean I > would like to see some more detailed data than just 'load > average' :-) I don't know the LPP (I think) that was mentioned before, but you should also look into using sar (System Accounting and Reporting) It's a (relatively) standard Unix tool for this sort of thing. HP has it standard on HPUX, and I know there is a free Linux version made by someone from 'At-Computing'. It's called atsar I don't know if it's packaged, I think so. Otherwise a search on freshmeat would turn it up. If that fails try contacting At on: www.atcomputing.nl (Even though their company is a direct competitor to mine ;) ) Mark Janssen Unix Consultant @ SyConOS IT E-mail: [EMAIL PROTECTED]GnuPG Key Id: 357D2178 http: markjanssen.homeip.net and markjanssen.[com|net|org|nl] Fax/VoiceMail: +31 84 8757555 Finger for GPG and GeekCode -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange grep or tail behaviour
On Tue, 1 May 2001, Jeremy C. Reed wrote: > But > tail -f access.log | grep GET > doesn't display anything (unless I wait awhile for several future entries). This should be: But tail -f access.log | grep GET | grep GET doesn't display anything (unless I wait awhile for several future entries). Any ideas?
strange grep or tail behaviour
Why does tail -f logfile | grep keyword | grep -v exclude-keyword react slow? In other words, if I do a "tail -f logfile | grep keyword" I immediately see results. But if I pipe the output into another grep, then the results are delayed until some buffer is filled up or a certain amount of lines is sent. For Example: $ tail -f ~/logs/access.log | grep postfix 10.1.175.3 - - [01/May/2001:12:04:40 -0700] "GET /software/virtualmail-pop3d/postfix.html HTTP/1.0" 304 - "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)" 10.160.213.200 - - [01/May/2001:12:05:02 -0700] "GET /software/virtualmail-pop3d/postfix.html HTTP/1.0" 200 7146 "-" "Lynx/2.8.2rel.1 libwww-FM/2.14" 10.160.213.200 - - [01/May/2001:12:07:53 -0700] "GET /software/virtualmail-pop3d/postfix.html HTTP/1.0" 200 7146 "-" "Lynx/2.8.2rel.1 libwww-FM/2.14" 10.160.213.200 - - [01/May/2001:12:07:55 -0700] "GET /software/virtualmail-pop3d/postfix.html HTTP/1.0" 200 7146 "-" "Lynx/2.8.2rel.1 libwww-FM/2.14" But when I do the following test: $ tail -f ~/logs/access.log | grep postfix | grep postfix Or: $ tail -f ~/logs/access.log | grep GET | grep -v BOGUS $ tail -f ~/logs/access.log | grep GET | grep G I get no results. I am watching the logs on another console and I know they are coming in. It does work if I use "cat" instead of "tail -f" So then I wait a while (maybe ten matches sent through) and it finally works. What causes this behaviour? What do I need to do to see the matches at once? For example, tail -f access.log | grep GET instantly shows many matches But tail -f access.log | grep GET doesn't display anything (unless I wait awhile for several future entries). By the way, I am using: grep (GNU grep) 2.4.2 tail (GNU textutils) 2. GNU bash, version 2.03.0(1)-release (i386-pc-linux-gnu) But I have now also seen this issue with different OSs and greps and tails. Jeremy C. Reed http://www.reedmedia.net/ http://bsd.reedmedia.net/ -- BSD news and resources http://www.isp-faq.com/-- find answers to your questions
Re: Performance monitor
> "m" == Marcin Owsiany <[EMAIL PROTECTED]> writes: m> Hello! I wonder what you guys use as performance m> monitoring/bottleneck detection software (preferably for a text m> terminal)? I mean I would like to see some more detailed data m> than just 'load average' :-) Why not try LTT? ;) I don't know if it's got a text frontend, though, although it shouldn't be difficult writing one. Bye, Andrea Glorioso
Re: strange grep or tail behaviour
On Tue, 1 May 2001, Jeremy C. Reed wrote: > But > tail -f access.log | grep GET > doesn't display anything (unless I wait awhile for several future entries). This should be: But tail -f access.log | grep GET | grep GET doesn't display anything (unless I wait awhile for several future entries). Any ideas? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Performance monitor
Hello! I wonder what you guys use as performance monitoring/bottleneck detection software (preferably for a text terminal)? I mean I would like to see some more detailed data than just 'load average' :-) Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
strange grep or tail behaviour
Why does tail -f logfile | grep keyword | grep -v exclude-keyword react slow? In other words, if I do a "tail -f logfile | grep keyword" I immediately see results. But if I pipe the output into another grep, then the results are delayed until some buffer is filled up or a certain amount of lines is sent. For Example: $ tail -f ~/logs/access.log | grep postfix 10.1.175.3 - - [01/May/2001:12:04:40 -0700] "GET /software/virtualmail-pop3d/postfix.html HTTP/1.0" 304 - "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)" 10.160.213.200 - - [01/May/2001:12:05:02 -0700] "GET /software/virtualmail-pop3d/postfix.html HTTP/1.0" 200 7146 "-" "Lynx/2.8.2rel.1 libwww-FM/2.14" 10.160.213.200 - - [01/May/2001:12:07:53 -0700] "GET /software/virtualmail-pop3d/postfix.html HTTP/1.0" 200 7146 "-" "Lynx/2.8.2rel.1 libwww-FM/2.14" 10.160.213.200 - - [01/May/2001:12:07:55 -0700] "GET /software/virtualmail-pop3d/postfix.html HTTP/1.0" 200 7146 "-" "Lynx/2.8.2rel.1 libwww-FM/2.14" But when I do the following test: $ tail -f ~/logs/access.log | grep postfix | grep postfix Or: $ tail -f ~/logs/access.log | grep GET | grep -v BOGUS $ tail -f ~/logs/access.log | grep GET | grep G I get no results. I am watching the logs on another console and I know they are coming in. It does work if I use "cat" instead of "tail -f" So then I wait a while (maybe ten matches sent through) and it finally works. What causes this behaviour? What do I need to do to see the matches at once? For example, tail -f access.log | grep GET instantly shows many matches But tail -f access.log | grep GET doesn't display anything (unless I wait awhile for several future entries). By the way, I am using: grep (GNU grep) 2.4.2 tail (GNU textutils) 2. GNU bash, version 2.03.0(1)-release (i386-pc-linux-gnu) But I have now also seen this issue with different OSs and greps and tails. Jeremy C. Reed http://www.reedmedia.net/ http://bsd.reedmedia.net/ -- BSD news and resources http://www.isp-faq.com/-- find answers to your questions -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Performance monitor
> "m" == Marcin Owsiany <[EMAIL PROTECTED]> writes: m> Hello! I wonder what you guys use as performance m> monitoring/bottleneck detection software (preferably for a text m> terminal)? I mean I would like to see some more detailed data m> than just 'load average' :-) Why not try LTT? ;) I don't know if it's got a text frontend, though, although it shouldn't be difficult writing one. Bye, Andrea Glorioso -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Performance monitor
Hello! I wonder what you guys use as performance monitoring/bottleneck detection software (preferably for a text terminal)? I mean I would like to see some more detailed data than just 'load average' :-) Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fckng null sender with Exim
Could you please stop those full quotes and reduce the quoted context to the relevant parts? On 01-04-30 Felipe Alvarez Harnecker wrote: > Bulent Murtezaoglu writes: > > > "ELBnet" == Tech Support <[EMAIL PROTECTED]> writes: > > ELBnet> Try using: headers_check_syntax = true headers_checks_fail > > ELBnet> = true > > ELBnet> which checks to be sure the From To BCC etc. are correctly > > ELBnet> formatted and rejects them if not. > > Which would do you no good for two reasons: > > 1- The original poster wants to block the null sender in the envelope > > from. > > 2- The null sender is a legitimate envelope from. > > Based on my e-mail interaction with the original poster (sender ?) > > I think what is being missed here is RFC 1123 which says > >5.2.9 Command Syntax: RFC-821 Section 4.1.2 > > The syntax shown in RFC-821 for the MAIL FROM: command omits > > the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page > > 15). An empty reverse path MUST be supported. > > and again in summary table 5.4, it says RECEIVER-SMTP _MUST_ send > > error notification messages using the null return path. > > If you block the null sender some nasty things happen. For example > > your customer sends off an important price quote to an important > > customer using the wrong e-mail address, the mail gets queued > > in some relay and eventually gets bounced (with null envelope sender), > > but since you refuse such messages your customer never finds out. [...] > Ok. I'm the original poster and what i want is: > Mails with a NULL sender with an invalid recipient get bounced to the > email address of any Header that happen to exists. > And if the recipient doesn't exists and > there is no way to bounce then reject. What you are suggesting here is a violent of the RfC. Bounces will always be send by a Mail-Server with MAIL FROM: <>. Rejecting or Bouncing this mail is a violation of the RfC, since the host should accept them and the postmaster should check those bounces then. So if you really want to create this setup, please refrain from connecting this mail-server to the internet and let customers use it, until it's properly configured according to the RfCs. Never reject or bounce any mail with MAIL FROM: <> in any way. This mail should always be accepted by a/your mailserver and the admin/postmaster should check them. If you really want to violate RfCs and connect a broken mail-server to the internet, then you should figure this one out on your own. But don't start wondering why in the future postmaster and users will get annoyed. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpY87wsVPpqB.pgp Description: PGP signature
Re: fckng null sender with Exim
Could you please stop those full quotes and reduce the quoted context to the relevant parts? On 01-04-30 Felipe Alvarez Harnecker wrote: > Bulent Murtezaoglu writes: > > > "ELBnet" == Tech Support <[EMAIL PROTECTED]> writes: > > ELBnet> Try using: headers_check_syntax = true headers_checks_fail > > ELBnet> = true > > ELBnet> which checks to be sure the From To BCC etc. are correctly > > ELBnet> formatted and rejects them if not. > > Which would do you no good for two reasons: > > 1- The original poster wants to block the null sender in the envelope > > from. > > 2- The null sender is a legitimate envelope from. > > Based on my e-mail interaction with the original poster (sender ?) > > I think what is being missed here is RFC 1123 which says > >5.2.9 Command Syntax: RFC-821 Section 4.1.2 > > The syntax shown in RFC-821 for the MAIL FROM: command omits > > the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page > > 15). An empty reverse path MUST be supported. > > and again in summary table 5.4, it says RECEIVER-SMTP _MUST_ send > > error notification messages using the null return path. > > If you block the null sender some nasty things happen. For example > > your customer sends off an important price quote to an important > > customer using the wrong e-mail address, the mail gets queued > > in some relay and eventually gets bounced (with null envelope sender), > > but since you refuse such messages your customer never finds out. [...] > Ok. I'm the original poster and what i want is: > Mails with a NULL sender with an invalid recipient get bounced to the > email address of any Header that happen to exists. > And if the recipient doesn't exists and > there is no way to bounce then reject. What you are suggesting here is a violent of the RfC. Bounces will always be send by a Mail-Server with MAIL FROM: <>. Rejecting or Bouncing this mail is a violation of the RfC, since the host should accept them and the postmaster should check those bounces then. So if you really want to create this setup, please refrain from connecting this mail-server to the internet and let customers use it, until it's properly configured according to the RfCs. Never reject or bounce any mail with MAIL FROM: <> in any way. This mail should always be accepted by a/your mailserver and the admin/postmaster should check them. If you really want to violate RfCs and connect a broken mail-server to the internet, then you should figure this one out on your own. But don't start wondering why in the future postmaster and users will get annoyed. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
