[7.386] Seeing a high number of postgres - unexpected EOF on client errors

I am seeing many postgresql unexpected EOF errors when reportcontrol.sh is invoked in the System Log.  This could also be an issue with the release of postgresql as well.

2009:01:24-01:15:01 gateway /usr/sbin/cron[21718]: (root) CMD (   /usr/local/bin/reportcontrol.sh)
2009:01:24-01:15:03 gateway backup[21720]: Configuration Auto Backup
2009:01:24-01:15:39 gateway postgres[21760]: [3-1] LOG:  unexpected EOF on client connection
2009:01:24-01:17:01 gateway /usr/sbin/cron[21794]: (root) CMD (  nice -n19 /usr/local/bin/gen_inline_reporting_data.plx)
2009:01:24-01:17:30 gateway postgres[21790]: [3-1] LOG:  unexpected EOF on client connection
2009:01:24-01:19:01 gateway /usr/sbin/cron[21823]: (root) CMD (/sbin/auisys.plx --nosys)
..
2009:01:24-03:10:01 gateway /usr/sbin/cron[23731]: (root) CMD (   /usr/local/bin/reportcontrol.sh)
2009:01:24-03:15:00 gateway postgres[23800]: [3-1] LOG:  unexpected EOF on client connection
..

Parents

0 BarryG over 16 years ago

I'm seeing roughly the same thing.

2009:01:24-00:10:01 fw /usr/sbin/cron[19622]: (root) CMD (   /usr/local/bin/reportcontrol.sh)

2009:01:24-00:10:33 fw dhcpc-sh: DHCP connection fine. Checking again in 60 seconds

2009:01:24-00:11:33 fw dhcpc-sh: DHCP connection fine. Checking again in 60 seconds

2009:01:24-00:12:33 fw dhcpc-sh: DHCP connection fine. Checking again in 60 seconds

2009:01:24-00:13:33 fw dhcpc-sh: DHCP connection fine. Checking again in 60 seconds

2009:01:24-00:14:33 fw dhcpc-sh: DHCP connection fine. Checking again in 60 seconds

2009:01:24-00:15:00 fw postgres[19720]: [3-1] LOG:  unexpected EOF on client connection

...

009:01:24-01:15:01 fw /usr/sbin/cron[21080]: (root) CMD (nice -n19 /usr/local/bin/create_rrd_graphs.plx)

2009:01:24-01:15:01 fw /usr/sbin/cron[21084]: (root) CMD (/usr/local/bin/backup.plx)

2009:01:24-01:15:01 fw /usr/sbin/cron[21082]: (root) CMD (   /usr/local/bin/reportcontrol.sh)

2009:01:24-01:15:05 fw backup[21084]: Configuration Auto Backup

2009:01:24-01:15:16 fw dhcpcd[3327]: corrupted UDP msg of size=1480 and uh_ulen=1852 discarded

2009:01:24-01:15:16 fw dhcpcd[3327]: corrupted UDP msg of size=372 and uh_ulen=16688 discarded

2009:01:24-01:15:35 fw dhcpc-sh: DHCP connection fine. Checking again in 60 seconds

2009:01:24-01:15:50 fw postgres[21116]: [3-1] LOG:  unexpected EOF on client connection

Barry

Reply

0 BarryG over 16 years ago

I'm seeing roughly the same thing.

2009:01:24-00:10:01 fw /usr/sbin/cron[19622]: (root) CMD (   /usr/local/bin/reportcontrol.sh)

2009:01:24-00:10:33 fw dhcpc-sh: DHCP connection fine. Checking again in 60 seconds

2009:01:24-00:11:33 fw dhcpc-sh: DHCP connection fine. Checking again in 60 seconds

2009:01:24-00:12:33 fw dhcpc-sh: DHCP connection fine. Checking again in 60 seconds

2009:01:24-00:13:33 fw dhcpc-sh: DHCP connection fine. Checking again in 60 seconds

2009:01:24-00:14:33 fw dhcpc-sh: DHCP connection fine. Checking again in 60 seconds

2009:01:24-00:15:00 fw postgres[19720]: [3-1] LOG:  unexpected EOF on client connection

...

009:01:24-01:15:01 fw /usr/sbin/cron[21080]: (root) CMD (nice -n19 /usr/local/bin/create_rrd_graphs.plx)

2009:01:24-01:15:01 fw /usr/sbin/cron[21084]: (root) CMD (/usr/local/bin/backup.plx)

2009:01:24-01:15:01 fw /usr/sbin/cron[21082]: (root) CMD (   /usr/local/bin/reportcontrol.sh)

2009:01:24-01:15:05 fw backup[21084]: Configuration Auto Backup

2009:01:24-01:15:16 fw dhcpcd[3327]: corrupted UDP msg of size=1480 and uh_ulen=1852 discarded

2009:01:24-01:15:16 fw dhcpcd[3327]: corrupted UDP msg of size=372 and uh_ulen=16688 discarded

2009:01:24-01:15:35 fw dhcpc-sh: DHCP connection fine. Checking again in 60 seconds

2009:01:24-01:15:50 fw postgres[21116]: [3-1] LOG:  unexpected EOF on client connection

Barry

Children

0 BAlfson over 16 years ago in reply to BarryG

I see the same thing in the V7.305 log.

Cheers - Bob
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 SlicerDicer over 16 years ago in reply to BAlfson

I am seeing the same thing.

7.386
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 BAlfson over 16 years ago in reply to SlicerDicer

Per Andreas, it's not a problem: https://community.sophos.com/products/unified-threat-management/astaroorg/f/53/p/32246/107800#107800

[GRUMBLE]
It's just another example of messages that Astaro expects everyone to ignore. You'd think they would at least create a list of this kind of mindless chatter so we know what NOT to worry about. This is just another example of the lack of attention to documentation.
[/GRUMBLE]

Cheers - Bob
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 andreas over 16 years ago in reply to BAlfson

Actually it's an example of a software developer archetype who stops working on an application when it reaches the state where it works as expected, and as long as there are real bugs out there cosmetic issues (like this one) are not important enough to justify allocating more time on them.
Unfortunately, creating documentation for this is not a good choice either because it would be more work to create and maintain documentation for it than to just solve the problem at it's root and fix the application.

Cheers,
andreas
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 trollvottel over 16 years ago in reply to andreas

Erm, no offence, but its up to the developer stating that a feature is finished. If its not completely ready and polished yet, don' t tell as if. Because things like that always come back like a Boomerang as you can see in this example. You always spend time dealing with things like that afterwards, either this or that way.

So, as a developer, just do it right rather than posting things that don' t help or change anything [:D]
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 BAlfson over 16 years ago in reply to andreas

Andreas, you know I'm a big fan of Astaro, but this is a problem that causes me way too much lost time convincing clients that there's no problem. Whenever there's the slightest problem with a new release, they get paranoid, and the questions begin again.

The only business any of us are in is taking care of other people. Not addressing this type of thing communicates to the customer that you care about the box, but not about how he feels. I know that's not your intent, but it is the message that's communicated.

This is NOT cosmetic.

Yours - Bob
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 theproto over 16 years ago in reply to andreas

I would tend to agree with you on the cosmetic issues to a point.

However, this is not just a cosmetic issue. While everything works as expected it seems that the client talking to Postgresql does not disconnect properly.

I've done some research on this and it is correctable with little work.

I understand if this is not a priority but believe it should be done before release.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 BarryG over 16 years ago in reply to theproto

However, this is not just a cosmetic issue. While everything works as expected it seems that the client talking to Postgresql does not disconnect properly.

In that case, this is a connection leak, which often can lead to exhaustion of server resources.

Barry
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 trollvottel over 16 years ago in reply to BarryG

No. Its just a warning that the connection was not closed by the application, but from the server daemon after timeout. Still, its not good style and basically you are right.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 andreas over 16 years ago in reply to trollvottel

Guys, please don't get me wrong on this.
I don't like it like it is. Bug reports for these log messages have been entered in our bug tracking system months ago. Unfortunately, there's nothing I can do at the moment except for telling you that you don't need to worry about these log messages.

Cheers,
andreas
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel