Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 12 replies
  • Subscribers 0 subscribers
  • Views 4439 views
  • Users 0 members are here
Options
Suggested

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

theproto
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
    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
  • 0 in reply to BarryG
    I see the same thing in the V7.305 log.

    Cheers - Bob
  • 0 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
  • 0 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
Reply
  • 0 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
Children
  • 0 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]
  • 0 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
  • 0 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.
  • 0 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
  • 0 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.
  • 0 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
  • 0 in reply to andreas
    Not tryin' to beat up on you, Andreas.  We're both in favor of increased success for Astaro people and products.

    Let me explain this another way.  Why did Toyota go from being a cheap Japanese car to the largest automaker in the world?  Quality and finishing at a very reasonable price.  I close the door on my six-year-old Toyota, and it still closes like a new Mercedes.  Astaro can be the Toyota of the UTM world.

    I'm not saying that nothing imperfect should ever be released, I'm saying that imperfections that communicate a lack of caring for the customer need to receive the priority they presently lack.

    Thanks for your participation here.

    Cheers - Bob