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

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)

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

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

"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

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

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

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

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 #

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

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

The sequence does not exist. Create the sequence and it will be fine

Darren Ferguson

On Wed, 29 May 2002, Remi wrote:

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 ?

Simple enough. The problem is that the tables you are importing had sequences associated with them. A sequence is simply a counter that increments every time it is used. This allows, say, your primary key to be created as 1, then 2, then 3, and so on. There are two things you can do to solve this problem:

1. Change the SQL that looks like this:

"mensajeid" int4 DEFAULT nextval('mensajes_mensajeid_seq'::text)

to this:

"mensajeid" SERIAL

2. Add create sequence statements to your SQL. They look like this:

CREATE SEQUENCE mensajes_mensajeid_seq START 101;

Change the number after "START" to be the largest number already in the table plus 1.

Beware that the first option may result in a collision of sequence numbers.

i.e. I import a record with a primary key of 1. Later I insert a record and the sequence is still set to 1. As a result, the inserted record has a primary key of 1. The database rejects the inserted record due to a primary key conflict.

Hope this helps,
Jerason

--
__________________________________________
Need a good Database management solution?
http://java.dnsalias.com

--
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

"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

----- 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 !