Thread: Invalid length of startup packet

Invalid length of startup packet

From
"Henrik Steffen"
Date:
(my apologies for the attachement in the last mail)

Hello all,

does anyone what the message "invalid length of startup packet"
in /var/log/messages means? It says it's "fatal" - so what is the reason
for this message, what does it mean and what can I do against it?

I use the latest postgresql-release on a heavily loaded dedicated pentium iv
machine.

Any help or information appreciated,

thanks


Mit freundlichem Gruß

Henrik Steffen
Geschäftsführer

top concepts Internetmarketing GmbH
Am Steinkamp 7 - D-21684 Stade - Germany
--------------------------------------------------------
http://www.topconcepts.com          Tel. +49 4141 991230
mail: steffen@topconcepts.com       Fax. +49 4141 991233
--------------------------------------------------------
24h-Support Hotline:  +49 1908 34697 (EUR 1.86/Min,topc)
--------------------------------------------------------
System-Partner gesucht: http://www.franchise.city-map.de
--------------------------------------------------------
Handelsregister: AG Stade HRB 5811 - UstId: DE 213645563
--------------------------------------------------------



Re: Invalid length of startup packet

From
Ron Snyder
Date:
If we portscan our database server and include the postgres port in the list
of scanned ports, we'll get that error in our logs.  You can also get that
message by attempting to telnet to your postgres port.  I'm a little
surprised that postgres doesn't list some source ip information with the
message.

-ron

> -----Original Message-----
> From: Henrik Steffen [mailto:steffen@city-map.de]
> Sent: Monday, May 27, 2002 2:16 AM
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] Invalid length of startup packet
>
>
> (my apologies for the attachement in the last mail)
>
> Hello all,
>
> does anyone what the message "invalid length of startup packet"
> in /var/log/messages means? It says it's "fatal" - so what is
> the reason
> for this message, what does it mean and what can I do against it?
>
> I use the latest postgresql-release on a heavily loaded
> dedicated pentium iv
> machine.
>
> Any help or information appreciated,
>
> thanks
>
>
> Mit freundlichem Gruß
>
> Henrik Steffen
> Geschäftsführer
>
> top concepts Internetmarketing GmbH
> Am Steinkamp 7 - D-21684 Stade - Germany
> --------------------------------------------------------
> http://www.topconcepts.com          Tel. +49 4141 991230
> mail: steffen@topconcepts.com       Fax. +49 4141 991233
> --------------------------------------------------------
> 24h-Support Hotline:  +49 1908 34697 (EUR 1.86/Min,topc)
> --------------------------------------------------------
> System-Partner gesucht: http://www.franchise.city-map.de
> --------------------------------------------------------
> Handelsregister: AG Stade HRB 5811 - UstId: DE 213645563
> --------------------------------------------------------
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>

Re: Invalid length of startup packet

From
"Henrik Steffen"
Date:
Dear Ron,

thanks for your answer. This is what happens if I telnet or portscan, too.

The thing is, that noone is actually telnetting or portscanning in. The
server
is located inside the DMZ of a firewall. There is only one webserver which
is allowed
to connect. This server is located inside the same DMZ. This can't be the
reason.

On the Webserver the Pg.pm perl-module is used to connect to the DB-Server.
This seems to be the origin of the error messages because this is the only
process
which is allowed to connect.

If I run the same perl-scripts from the command prompt theres is no problem.
But using
Apache 1.3.24 with latest mod_perl the error message in /var/log/messages is
generated.

This is really weird.

I upgraded to the latest postgresql-rpm yesterday on both the Webserver and
the Db-Server,
this didn't change anything.

Additionally, the error is non-fatal: The connection is not dropped. Anyway,
the message
has got to have some reason, hasn't it?

Any comments?

Mit freundlichem Gruß

Henrik Steffen
Geschäftsführer

top concepts Internetmarketing GmbH
Am Steinkamp 7 - D-21684 Stade - Germany
--------------------------------------------------------
http://www.topconcepts.com          Tel. +49 4141 991230
mail: steffen@topconcepts.com       Fax. +49 4141 991233
--------------------------------------------------------
24h-Support Hotline:  +49 1908 34697 (EUR 1.86/Min,topc)
--------------------------------------------------------
System-Partner gesucht: http://www.franchise.city-map.de
--------------------------------------------------------
Handelsregister: AG Stade HRB 5811 - UstId: DE 213645563
--------------------------------------------------------

----- Original Message -----
From: "Ron Snyder" <snyder@roguewave.com>
To: "'Henrik Steffen'" <steffen@city-map.de>; <pgsql-general@postgresql.org>
Sent: Tuesday, May 28, 2002 6:37 AM
Subject: Re: [GENERAL] Invalid length of startup packet


If we portscan our database server and include the postgres port in the list
of scanned ports, we'll get that error in our logs.  You can also get that
message by attempting to telnet to your postgres port.  I'm a little
surprised that postgres doesn't list some source ip information with the
message.

-ron

> -----Original Message-----
> From: Henrik Steffen [mailto:steffen@city-map.de]
> Sent: Monday, May 27, 2002 2:16 AM
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] Invalid length of startup packet
>
>
> (my apologies for the attachement in the last mail)
>
> Hello all,
>
> does anyone what the message "invalid length of startup packet"
> in /var/log/messages means? It says it's "fatal" - so what is
> the reason
> for this message, what does it mean and what can I do against it?
>
> I use the latest postgresql-release on a heavily loaded
> dedicated pentium iv
> machine.
>
> Any help or information appreciated,
>
> thanks
>
>
> Mit freundlichem Gruß
>
> Henrik Steffen
> Geschäftsführer
>
> top concepts Internetmarketing GmbH
> Am Steinkamp 7 - D-21684 Stade - Germany
> --------------------------------------------------------
> http://www.topconcepts.com          Tel. +49 4141 991230
> mail: steffen@topconcepts.com       Fax. +49 4141 991233
> --------------------------------------------------------
> 24h-Support Hotline:  +49 1908 34697 (EUR 1.86/Min,topc)
> --------------------------------------------------------
> System-Partner gesucht: http://www.franchise.city-map.de
> --------------------------------------------------------
> Handelsregister: AG Stade HRB 5811 - UstId: DE 213645563
> --------------------------------------------------------
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)


Re: Invalid length of startup packet

From
Tom Lane
Date:
Ron Snyder <snyder@roguewave.com> writes:
> If we portscan our database server and include the postgres port in the list
> of scanned ports, we'll get that error in our logs.  You can also get that
> message by attempting to telnet to your postgres port.  I'm a little
> surprised that postgres doesn't list some source ip information with the
> message.

It would be fairly easy to rearrange the code in postmaster.c so that
a log message like "attempted connection from host xxx port yyy" is
emitted before we try to receive and interpret the startup packet.
But I don't think we can guarantee that every error condition that might
occur in that stretch of code could be modified to include host/port in
the text of the error message.  So the "attempted connection" message
would have to be logged unconditionally for every connection attempt.
Does that seem useful?  Would you want it to be automatic when
LOG_CONNECTIONS is on, or should it require some higher-than-normal
debug setting?

            regards, tom lane

Re: Invalid length of startup packet

From
"Nigel J. Andrews"
Date:
On Tue, 28 May 2002, Tom Lane wrote:

> Ron Snyder <snyder@roguewave.com> writes:
> > If we portscan our database server and include the postgres port in the list
> > of scanned ports, we'll get that error in our logs.  You can also get that
> > message by attempting to telnet to your postgres port.  I'm a little
> > surprised that postgres doesn't list some source ip information with the
> > message.
>
> It would be fairly easy to rearrange the code in postmaster.c so that
> a log message like "attempted connection from host xxx port yyy" is
> emitted before we try to receive and interpret the startup packet.
> But I don't think we can guarantee that every error condition that might
> occur in that stretch of code could be modified to include host/port in
> the text of the error message.  So the "attempted connection" message
> would have to be logged unconditionally for every connection attempt.
> Does that seem useful?  Would you want it to be automatic when
> LOG_CONNECTIONS is on, or should it require some higher-than-normal
> debug setting?

I just looked at the ProcessStartupPacket code to see about doing a patch. I
noticed a few elog()s and thought that supplying the remote connection
information to cover all of these would be a bit of a hassle. Then I wondered
if it was necessary since I presumed all connections could be logged, if a
fatal error occurs the connection won't be listed by netstat by the time
someone looks, so all that's needed is that the connection log records the
information.

Obviously, that's not entirely usable if connections are being made and dropped
by applications. So how about elog() sticking the backend slot number into all
messages? Is that sort of information available in elog? (I'm just looking at
that now but can't say after only a quick scan and with my small knowledge of
the backend code)


--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants


Re: Invalid length of startup packet

From
Tom Lane
Date:
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> Obviously, that's not entirely usable if connections are being made
> and dropped by applications. So how about elog() sticking the backend
> slot number into all messages? Is that sort of information available
> in elog?

No; in fact there is no backend slot number assigned yet during startup
processing.  But elog already can record the process PID, and that's
probably what you'd want to use to correlate these messages.  I'm
envisioning log entries like

timestamp [PID] LOG: received connection from foo.bar port 12345
timestamp [PID] FATAL: Invalid length of startup packet

The PID in the first of these messages would already be the PID of the
forked-off child, so there would be a clear correlation to the following
failure message, even if other connection requests were being processed
at about the same time.

            regards, tom lane

Re: Invalid length of startup packet

From
Ron Snyder
Date:
>
> timestamp [PID] LOG: received connection from foo.bar port 12345
> timestamp [PID] FATAL: Invalid length of startup packet
>
> The PID in the first of these messages would already be the PID of the
> forked-off child, so there would be a clear correlation to
> the following
> failure message, even if other connection requests were being
> processed
> at about the same time.

That works for me, although won't there will be some redundancy in some
cases?
May 28 09:14:55 vault pgqv[4332]: [1] DEBUG:  connection:
host=172.21.41.62:3586 user=dbuser database=test

I can live with that redundancy, especially considering that some of our
logging tools rely on those three pieces of information being together.

If the output becomes something similar to this:
May 28 09:14:55 vault pgqv[4332]: [1] DEBUG:  connection:
host=172.21.41.62:3586
May 28 09:14:55 vault pgqv[4332]: [2] DEBUG:  authorize: user=dbuser
database=test

Or
May 28 09:14:55 vault pgqv[4332]: [1] DEBUG:  connection:
host=172.21.41.62:3586
May 28 09:14:55 vault pgqv[4332]: [2] FATAL: Invalid length of startup
packet
Then we (my group) could adjust.  We're flexible. :)

To answer an earlier question:
> the text of the error message.  So the "attempted connection" message
> would have to be logged unconditionally for every connection attempt.
> Does that seem useful?  Would you want it to be automatic when
> LOG_CONNECTIONS is on, or should it require some higher-than-normal
> debug setting?

I think that it should be automatic when LOG_CONNECTIONS is on. I have
connection logging on specifically so I can discover this _type_ of problem.
(specifically, relating problems seen later in a connection back to the
client that initiated it)

-ron

Re: Invalid length of startup packet

From
Tom Lane
Date:
Ron Snyder <snyder@roguewave.com> writes:
> If the output becomes something similar to this:
> May 28 09:14:55 vault pgqv[4332]: [1] DEBUG:  connection: host=172.21.41.62:3586
> May 28 09:14:55 vault pgqv[4332]: [2] DEBUG:  authorize: user=dbuser database=test

I kinda like that approach, actually, with both messages driven off the
LOG_CONNECTIONS flag.  Does anyone really hate it?

            regards, tom lane

Re: Invalid length of startup packet

From
Tom Lane
Date:
> Ron Snyder <snyder@roguewave.com> writes:
>> If the output becomes something similar to this:
>> May 28 09:14:55 vault pgqv[4332]: [1] DEBUG:  connection: host=172.21.41.62:3586
>> May 28 09:14:55 vault pgqv[4332]: [2] DEBUG:  authorize: user=dbuser database=test

> I kinda like that approach, actually, with both messages driven off the
> LOG_CONNECTIONS flag.  Does anyone really hate it?

I've committed changes to split LOG_CONNECTIONS logging into two parts.
CVS tip now produces one message as soon as a connection is received
(well, actually just after a successful fork() to handle the connection)
and another at successful conclusion of the authentication phase:

2002-05-28 19:47:42 [18108]  LOG:  connection received: host=127.0.0.1 port=1117
2002-05-28 19:47:42 [18108]  LOG:  connection authorized: user=postgres database=regression

In error cases you'd get log results like this:

2002-05-28 19:48:20 [18114]  LOG:  connection received: host=192.168.1.3 port=1119
2002-05-28 19:48:20 [18114]  FATAL:  No pg_hba.conf entry for host 192.168.1.3, user postgres, database postgres
2002-05-28 19:48:38 [18116]  LOG:  connection received: host=127.0.0.1 port=1120
2002-05-28 19:48:42 [18116]  FATAL:  invalid length of startup packet

(the last is from a manual telnet connection).

            regards, tom lane

Re: Invalid length of startup packet

From
Jan Wieck
Date:
Tom Lane wrote:
> Ron Snyder <snyder@roguewave.com> writes:
> > If the output becomes something similar to this:
> > May 28 09:14:55 vault pgqv[4332]: [1] DEBUG:  connection: host=172.21.41.62:3586
> > May 28 09:14:55 vault pgqv[4332]: [2] DEBUG:  authorize: user=dbuser database=test
>
> I kinda like that approach, actually, with both messages driven off the
> LOG_CONNECTIONS flag.  Does anyone really hate it?

    In  addition I would suggest that these two messages are also
    printed before the first real elog() output occurs,  if  that
    flag is turned off.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



Re: Invalid length of startup packet

From
Tom Lane
Date:
Jan Wieck <janwieck@yahoo.com> writes:
>     In  addition I would suggest that these two messages are also
>     printed before the first real elog() output occurs,  if  that
>     flag is turned off.

Uh, what do you mean by "real elog() output"?  In any case, there is
not a lot of choice about the placement of these messages AFAICS.

            regards, tom lane

Error class not found

From
"Remi"
Date:
Y have import a table of  PostgreSQL 7.0.3  in the  PostgreSQL 7.2.1  with
PhpPgAdmin and a file.sql below:
-----------------------------------------------------------
CREATE TABLE "mensajes" (
   "mensajeid" int4 DEFAULT nextval('mensajes_mensajeid_seq'::text) NOT
NULL,
   "usuarioid" int4 NOT NULL,
   "fechacreacion" timestamp NOT NULL,
   "asunto" varchar(255) NOT NULL,
   "cuerpo" text NOT NULL,
   CONSTRAINT "mensajes_pkey" PRIMARY KEY ("mensajeid")
);
CREATE  INDEX "mensajes_usuarioid_key" ON "mensajes" ("usuarioid");
/* --------------------------------------------------------
  Dumping data for table "mensajes"
-------------------------------------------------------- */
INSERT INTO "mensajes" ("usuarioid", "fechacreacion", "asunto", "cuerpo")
VALUES(35, 1, '2002-04-21 04:58:54+02', 'aa', 'a');
... / ...
INSERT INTO "mensajes" ("usuarioid", "fechacreacion", "asunto", "cuerpo")
VALUES(87, 9, '2002-05-23 19:14:38+02', 'Re: Mensaje de prueba', 'De remi');
-----------------------------------------------------------

The structure is :
-----------------------------------------------------------
Field               Type            Length    Not Null    Default
mensajeid        int4             4             Yes
nextval('mensajes_mensajeid_seq'::text)
usuarioid         int4             4              Yes
fechacreacion timestamptz 8              Yes
asunto            varchar        255          Yes
cuerpo           text var                         Yes

Keyname                         Unique   Primary   Field
mensajes_pkey                Yes        Yes         mensajeid
mensajes_usuarioid_key   No        No           usuarioid
-----------------------------------------------------------

When y use a INSERT query:
INSERT INTO mensajes (usuarioid, asunto, cuerpo, fechacreacion)
VALUES (35, 'sd', 'sd', '2002-05-29 21:22:34')

y have this error
ERROR:  pg_aclcheck: class "mensajes_mensajeid_seq" not found

y have this with all table width the nextval('xxx_xxx_seq'::text) option

Does any one help me please ?

Thank you

Remi


Re: Error class not found

From
Darren Ferguson
Date:
The sequence does not exist. Create the sequence and it will be fine

Darren Ferguson

On Wed, 29 May 2002, Remi wrote:

> Y have import a table of  PostgreSQL 7.0.3  in the  PostgreSQL 7.2.1  with
> PhpPgAdmin and a file.sql below:
> -----------------------------------------------------------
> CREATE TABLE "mensajes" (
>    "mensajeid" int4 DEFAULT nextval('mensajes_mensajeid_seq'::text) NOT
> NULL,
>    "usuarioid" int4 NOT NULL,
>    "fechacreacion" timestamp NOT NULL,
>    "asunto" varchar(255) NOT NULL,
>    "cuerpo" text NOT NULL,
>    CONSTRAINT "mensajes_pkey" PRIMARY KEY ("mensajeid")
> );
> CREATE  INDEX "mensajes_usuarioid_key" ON "mensajes" ("usuarioid");
> /* --------------------------------------------------------
>   Dumping data for table "mensajes"
> -------------------------------------------------------- */
> INSERT INTO "mensajes" ("usuarioid", "fechacreacion", "asunto", "cuerpo")
> VALUES(35, 1, '2002-04-21 04:58:54+02', 'aa', 'a');
> ... / ...
> INSERT INTO "mensajes" ("usuarioid", "fechacreacion", "asunto", "cuerpo")
> VALUES(87, 9, '2002-05-23 19:14:38+02', 'Re: Mensaje de prueba', 'De remi');
> -----------------------------------------------------------
>
> The structure is :
> -----------------------------------------------------------
> Field               Type            Length    Not Null    Default
> mensajeid        int4             4             Yes
> nextval('mensajes_mensajeid_seq'::text)
> usuarioid         int4             4              Yes
> fechacreacion timestamptz 8              Yes
> asunto            varchar        255          Yes
> cuerpo           text var                         Yes
>
> Keyname                         Unique   Primary   Field
> mensajes_pkey                Yes        Yes         mensajeid
> mensajes_usuarioid_key   No        No           usuarioid
> -----------------------------------------------------------
>
> When y use a INSERT query:
> INSERT INTO mensajes (usuarioid, asunto, cuerpo, fechacreacion)
> VALUES (35, 'sd', 'sd', '2002-05-29 21:22:34')
>
> y have this error
> ERROR:  pg_aclcheck: class "mensajes_mensajeid_seq" not found
>
> y have this with all table width the nextval('xxx_xxx_seq'::text) option
>
> Does any one help me please ?
>
> Thank you
>
> Remi
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>


Re: Error class not found

From
Tom Lane
Date:
"Remi" <gemegesola@retemail.es> writes:
> Y have import a table of  PostgreSQL 7.0.3  in the  PostgreSQL 7.2.1  with
> PhpPgAdmin and a file.sql below:

> ERROR:  pg_aclcheck: class "mensajes_mensajeid_seq" not found

Looks like you (or PG 7.0.3's pg_dump) forgot to include the
    CREATE SEQUENCE mensajes_mensajeid_seq;
command.  You will want to do that, and probably also do a setval()
to set the sequence to whatever count it should have.

            regards, tom lane

Re: Error class not found

From
"Darko Prenosil"
Date:
----- Original Message -----
From: "Remi" <gemegesola@retemail.es>
To: <pgsql-general@postgresql.org>
Sent: Wednesday, May 29, 2002 9:49 PM
Subject: [GENERAL] Error class not found


> Y have import a table of  PostgreSQL 7.0.3  in the  PostgreSQL 7.2.1  with
> PhpPgAdmin and a file.sql below:
> -----------------------------------------------------------
> CREATE TABLE "mensajes" (
>    "mensajeid" int4 DEFAULT nextval('mensajes_mensajeid_seq'::text) NOT
> NULL,
>    "usuarioid" int4 NOT NULL,
>    "fechacreacion" timestamp NOT NULL,
>    "asunto" varchar(255) NOT NULL,
>    "cuerpo" text NOT NULL,
>    CONSTRAINT "mensajes_pkey" PRIMARY KEY ("mensajeid")
> );
> CREATE  INDEX "mensajes_usuarioid_key" ON "mensajes" ("usuarioid");

If You use sintax "int4 DEFAULT nextval" instead of "SERIAL" this means that
you need also to CREATE SEQUENCE by Your self. When SERIAL sintax is used,
server
automaticaly creates this sequence for you. You can find more about it in
the documentation.

What You did is "View dump (schema) of table" from phpPgAdmin, and that dump
shows only
dump of that table.
If You try to execute "View dump (schema) of database" from phpPgAdmin,
somewhere in the dump
You will find :

CREATE SEQUENCE "mensajes_mensajeid_seq" start 1 increment 1 maxvalue
9223372036854775807 minvalue 1 cache 1;

You need to execute this line too against database, and things will work
just fine.

Regards !