Jump to content

Cannot open database connection in getGrid


kae

Recommended Posts

I got these informational messages during the parsing phase of reporting an email as spam. I cancelled the report and then a few minutes later enetered the information again and got the same message. I did a search for getGrid and saw something about slowness, but I'm wondering what to do when I get this message. My question is: Should I go ahead and hit the "Send spam Report(s) Now" button or do I need to do something else.

Here's the Tracking URL:

http://www.spamcop.net/sc?id=z777574494z55...c930e7dbeecf9dz

I pulled up the tracking URL and it seemed like when I looked at it there was no getGrid message and it seemed to have parsed fine, so I hit the Send spam Reports button on the trackin URL page. I'm not sure why I got the getGrid message unless it was just a freak occurance, but it happened twice. Anyway, my question is do I go ahead and hit the send reports button or is there some other action that I should do?

Here is what I saw in the reports section, well at least the text, the report was a lot prettier:

[color="green"]Parsing header:[/color]
[color="red"]Cannot open database connection in getGrid[/color]


Received:  (qmail 29237 invoked from network); 22 Jun 2005 10:31:10 -0000
Ignored


Received:  from unknown (HELO c60.cesmail.net) (192.168.1.105) by blade3.cesmail.net with SMTP; 22 Jun 2005 10:31:10 -0000
192.168.1.105 found
host 192.168.1.105 (getting name) no name
host 192.168.1.105 = Computer2-ATM3-1.2.gw.psu.edu (old cache)

192.168.1.105 discarded


Received:  from mailgate.cesmail.net (216.154.195.36) by c60.cesmail.net with ESMTP; 22 Jun 2005 06:31:04 -0400
216.154.195.36 found
host 216.154.195.36 = mailgate.cesmail.net (cached)
mailgate.cesmail.net is 216.154.195.36
Possible spammer: 216.154.195.36
Received line accepted
Relay trusted (216.154.195.36 cesmail.net mailgate.cesmail.net)


Received:  from mail.xnet.com [198.147.221.67] by mailgate.cesmail.net with POP3 (fetchmail-6.2.1) for x (single-drop); Wed, 22 Jun 2005 06:31:03 -0400 (EDT)
198.147.221.67 found
Checking POP client chain:
   Chain test:mailgate.cesmail.net =? 216.154.195.36
   ips are close enough
   216.154.195.36 is close to an MX (216.154.195.53) for cesmail.net
   216.154.195.36 is mx
   mailgate.cesmail.net and 216.154.195.36 have close IP addresses - chain verified
POP hack, restarting chain.


Received:  by earth1-b1.xnet.com (Postfix, from userid 56) id 4BDF31625; Wed, 22 Jun 2005 05:16:19 -0500 (CDT)
Ignored


Received:  from inferno1.xnet.com (inferno1.xnet.com [198.147.221.81]) by earth1-a2.xnet.com (Postfix) with ESMTP id 4FFF51625; Wed, 22 Jun 2005 05:16:18 -0500 (CDT)
198.147.221.81 found
host 198.147.221.81 = inferno1.xnet.com (cached)
inferno1.xnet.com is 198.147.221.81
Possible spammer: 198.147.221.81
ips are close enough
198.147.221.81 is close to an MX (198.147.221.71) for xnet.com
198.147.221.81 is mx
Received line accepted


Received:  from inferno1 (localhost.localdomain [127.0.0.1]) by inferno1.xnet.com (Postfix) with SMTP id 4272E101BB7; Wed, 22 Jun 2005 05:16:18 -0500 (CDT)
127.0.0.1 found
host 127.0.0.1 = localhost (cached)
localhost is 127.0.0.1
198.147.221.81 not listed in dnsbl.njabl.org
198.147.221.81 not listed in cbl.abuseat.org
198.147.221.81 not listed in dnsbl.sorbs.net
198.147.221.81 is not an MX for earth1-a2.xnet.com
ips are close enough
198.147.221.81 is close to an MX (198.147.221.71) for xnet.com

127.0.0.1 discarded


Received:  from earth1.xnet.com ([198.147.221.71]) by inferno1 ([198.147.221.81]) with SMTP (gateway) id A053DF3A3C6; Wed, 22 Jun 2005 05:16:18 -0500
Masking IP-based 'by' clause.

Received:  from earth1.xnet.com ([198.147.221.71]) by inferno1 with SMTP (gateway) id A053DF3A3C6; Wed, 22 Jun 2005 05:16:18 -0500
198.147.221.71 found
host 198.147.221.71 = earth1.xnet.com (cached)
earth1.xnet.com is 198.147.221.71
198.147.221.81 not listed in dnsbl.njabl.org
198.147.221.81 not listed in cbl.abuseat.org
198.147.221.81 not listed in dnsbl.sorbs.net
198.147.221.81 is not an MX for earth1-a2.xnet.com
ips are close enough
198.147.221.81 is close to an MX (198.147.221.71) for xnet.com
Possible spammer: 198.147.221.71
inferno1 is not a hostname
   Chain test:inferno1 =? inferno1.xnet.com
   inferno1 and inferno1.xnet.com have same hostname - chain verified
Possible relay: 198.147.221.81
198.147.221.81 not listed in relays.ordb.org.
198.147.221.81 has already been sent to relay testers
Received line accepted


Received:  from 198.147.221.71 (unknown [219.254.177.219]) by earth1-a1.xnet.com (Postfix) with SMTP id AFE591625; Wed, 22 Jun 2005 05:16:02 -0500 (CDT)
219.254.177.219 found
host 219.254.177.219 (getting name) no name
198.147.221.71 not listed in dnsbl.njabl.org
198.147.221.71 not listed in cbl.abuseat.org
198.147.221.71 not listed in dnsbl.sorbs.net
198.147.221.71 is an MX for xnet.com
Possible spammer: 219.254.177.219
host earth1-a1.xnet.com (checking ip) ip not found ; earth1-a1.xnet.com discarded as fake.
   Chain test:earth1-a1.xnet.com =? earth1.xnet.com
   host earth1.xnet.com (checking ip) = 198.147.221.71
   198.147.221.71 is an MX for xnet.com
   198.147.221.71 is mx
   earth1-a1.xnet.com and earth1.xnet.com have close IP addresses - chain verified
Possible relay: 198.147.221.71
198.147.221.71 not listed in relays.ordb.org.
198.147.221.71 has already been sent to relay testers
Received line accepted


Received:  from dns61alex4all.com ([133.177.249.128]) by vip8-js3.ezdell77[at]gmail.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 22 Jun 2005 04:11:51 -0700
133.177.249.128 found
host 133.177.249.128 (getting name) no name
219.254.177.219 not listed in dnsbl.njabl.org
219.254.177.219 listed in cbl.abuseat.org ( 127.0.0.2 )
Open proxies untrusted as relays

Tracking message source: 219.254.177.219:
Routing details for 219.254.177.219
[refresh/show] Cached whois for 219.254.177.219 : nospam[at]hanaro.com ip-adm[at]hanaro.com
Using abuse net on nospam[at]hanaro.com
abuse net hanaro.com = abuse[at]hanaro.com
Using best contacts abuse[at]hanaro.com
Message is 5 hours old
219.254.177.219 not listed in dnsbl.njabl.org
219.254.177.219 not listed in dnsbl.njabl.org
219.254.177.219 listed in cbl.abuseat.org ( 127.0.0.2 )
219.254.177.219 is an open proxy
219.254.177.219 not listed in accredit.habeas.com
219.254.177.219 not listed in plus.bondedsender.org
219.254.177.219 not listed in iadb.isipp.com

Finding links in message body
Parsing text part
no links found

Please make sure this email IS spam: 
From: "New Nu Body" <ezdell77[at]gmail.com> ()
 want to make 1500.00 to 3500.00 per day just for returning phone calls? If you 
 have a telephone and can return calls then you are qualified

Link to comment
Share on other sites

Just came from the newsgroups, one similar query/complaint there about this .. same comment made, a Refresh seemed to have cleared up the parse.

Based on what I/'we' know .... part of Ironport's acquisition was the addition of more hardware ... easy 'guess' right now on the error you're seeing is that there is some work being done on the networked systems down in IronPort land, and there are some communication issues between some of those systems. With the belief that there are folks on site, and that systems are configured to send out various alarms, one could go with these failures haven't gone unnoticed .. and/or the maintenance issues will be completed in a bit.

on the other hand, if you're still seeing this later on today, bring on your alert!

Link to comment
Share on other sites

on the other hand, if you're still seeing this later on today, bring on your alert!

29456[/snapback]

I've received the same results periodically during the past 3 days, as well as the NoMaster error statements referred to in another post. My best guess is that 10-15% of my reported emails began producing these results and since it's gone on for several days now, it's more than a short-term transition or maintenance issue.

Link to comment
Share on other sites

I've received the same results periodically during the past 3 days, as well as the NoMaster error statements referred to in another post.  My best guess is that 10-15% of my reported emails began producing these results and since it's gone on for several days now, it's more than a short-term transition or maintenance issue.

29460[/snapback]

OK, note made. I've said in the past that I manually report the majority of my spam, usually only using the SpamCop parser to double-check or analyze something that isn't clear .. or analyzing someone else's spam to see why they got their results ... so I can state that I've not seen the "grid" issue, and noting that as I type this, there is still only the one newsgroup post amd now two users talking about it here .... making it look more like a spammy construct that may be involved, and as yet, no Tracking URLs have been provided for that 'research' mode to kick in from 'here' .... I've already got several e-mails out to the Deputies/Don on some other issues ... can't see how to escalate this without some background data at present.

Link to comment
Share on other sites

I think I posted the tracking URL (was it the wrong URL)? I hope I got the right one. It was what I got when the grid issue happened, but if you look at the tracking URL, it doesn't show the problem.

When you bring up the tracking URL, does it go through the parser again? I konw when I look at what I've reported I can send it through the parser again, but I don't know if the tracking URL sends it through again or not.

This grid thing seems like just some temporary intermittent access problem. I tried to put the same information through the parser again by putting the headers and body text into the reporting tool, but it didn't come up with the same error; even though I got it twice in a row the last time. So, I just cancelled the additional report. The grid problem is probably just what Wazoo said it was. I doubt that it has anything to do with the parser.

I would expect that the only place you're going to find this getGrid problem reported is if it's logged into some programs stderr or stdout and saved on the spamcop servers.

I was a little afraid that those quick reports that I always do from the Held Mail might have failed, but I looked through my spam reports and didn't see the grid problem reported, so I'm guessing that they're okay.

I think this getGrid thing is different than the nomaster problem.

Have I said how annoying it is when the spammers start using your own spamcop.net email address to send their spam out? All you get is the blasted return message from the postmaster. Some at least give you the satisfaction of putting the headers in so you can send the abuse administrators a message of your own. Oh, so annoying, but I digress. I'll keep my eyes open for more getGrid problems.

Link to comment
Share on other sites

Wazoo:

I had the same experience as Kae reported. Went back into reported messages to pull some tracking URL's where the GetGrid issue had occurred, but the message had no record of GetGrid and re-parsing produced no problems. So, I assume the issue was temporary -- either due to spam construction or the hardware transition process, but appears to be over. If I run into it again, I'll come back with the tracking URL.

Link to comment
Share on other sites

The request for a Tracking URL is done to work around a bunch of other issues ... this application for instance handles white space poorly. Then there's the problem of what was actually sent via e-mail, handled via a number of servers, rendered in some user e-mail application, copied via another tool, pasted into a post here ... usual scenario there is that while I 'fix' that post to try to run that through the parser, I normally end up with 'no problem seen' ..

The downside of the Tracking URL is as noted in the above ... yes, hitting that URL does in fact cause a re-parse ... and due to things changing in the meantime, we do run into that "was a problem at 1000, works fine at 1400" ...

newsgroup traffic has been slow enough today that I was actually beginning to think that something was wrong at my end ... but a posting there just showed up and was received, so .... point there being that any screw-up in the parsing/reporting engine normally causes a lot of traffic there, usually by the folks that don't "read before posting" .. but thus far, still that one post there, and the reports here in this Topic. I'm sure that spam hasn't magically stopped <g> ...

There is a 'similar' error that shows up when the database starts getting hosed, but there is more data in that error message, usually detailing a "putrow" issue being involved. I haven't seen that one pop up in quite a while, noting that when this one shows up, everybody gets impacted ...

Now, taking a look at kae's first post which included both a Tracking URL and a copy of the parse .. hit the Tracking URL link ... first thing I note is that the current parse shows that kae's reporting account is configured to use MailHost stuff .. However, looking at the copied parse results in that first post, there is no MailHost data showing in that parse ... hmmmm ...

What I'm looking at is the 'numbered' line separators for each line of the parse ...

Parsing header:

0: Received: from unknown (HELO c60.cesmail.net) (192.168.1.105) by blade3.cesmail.net with SMTP; 22 Jun 2005 10:31:10 -0000

Internal handoff at SpamCop

1: Received: from mailgate.cesmail.net (216.154.195.36) by c60.cesmail.net with ESMTP; 22 Jun 2005 06:31:04 -0400

Hostname verified: mailgate.cesmail.net

SpamCop received mail from SpamCop ( 216.154.195.36 )

as compared to the data shown in kae's first post (gave up trying to copy data here, once again, white-space issues involved <g>)

Note kicked upstream on the possible MailHost server connection problem.

Link to comment
Share on other sites

One additional problem using tracking ULR's is that when the parser processes a message that has already been reported it handles it differently and displays the results somewhat differently. Add that to the fact that the parse is time sensitive and the results can be quite different.

One other thing to try is to resubmit the message and reparse it that way and see if you still get the same GetGrid message (Remember to cancel the reports to avoid double reporting) You could then copy and paste that part of the parse as part our your reply along with the tracking ULR.

Link to comment
Share on other sites

My guess at what happened is that at some point in time the parser was unable to get my MailHost information from where ever the parser gets it (maybe that's the getGrid stuff) and the parser just parsed the email as though I didn't have any MailHost information (i.e. all received lines are suspect).

Anyway, what I posted in the Code section of the first post was the text shown on the webpage from the parsed output that comes from hitting the "Process spam" button on the "Report spam" webpage. What I copied into the code section came off of the webpage report which was a lot prettier than the cut and paste job I did. I tried to colorize the getGrid error message, but wasn't too successful about getting the spacing and stuff, so it didn't look like the webpage at all. I am sorry about that. Maybe I should have posted the html source.... Anyway...

The main mailhost that the spammers seem to know about and use has (what I think is a) complicated mail handling system. There are about six received lines of mail handlers. All of my mailhosts (including the one this email came through) have been added via the "Add New Host" on the MailHosts tab in the Report spam webpage, so the information is there and since I've never seen a problem with it before nor since the problem I had this morning, it seems like a freak occurance.

This morning, I did cancel the first report I submitted that had the getGrid error and went ahead and read the rest of my email and came back and submitted it again a minute or two later. The second time it had the same getGrid error, but when I looked at the Tracking URL at the top of the page (opened new webpage and looked) it had parsed correctly using the correct MailHost information. On the bottom of the new webpage with the correct parse it showed that I could submit the information so I did from the new page.

Link to comment
Share on other sites

E-mail response ... newsgroup post added that programmers and ops people are aware of it ....

Yes, it was a glitch with the db holding the MH data. Thanks

Ellen

SpamCop

Please include all previous correspondence with replies

----- Original Message -----

From: "Wazoo"

To: Deputies

Sent: Wednesday, June 22, 2005 7:00 PM

Subject: MailHost data/server connection issue?

> Newsgroups: spamcop

> Message-ID: <d9bvdh$cvd$1[at]news.spamcop.net>

> Subject: Parser warning or error message

>

> http://forum.spamcop.net/forums/index.php?showtopic=4417

>

> Appearances seem to suggest some kind of issue with

> connecting to the server that holds the MailHost data.

> Error message is;

> Parsing header:Cannot open database connection in getGrid

>

> Parse results in one case show no MailHost data lines in

> use, but a Refresh seems to clear things up.  Hitting the

> Tracking URL (in my case) had the parser running

> correctly, showing the MailHost numbered line type

> parse output.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...