Thread: 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 --------------------------------------------------------
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 >
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 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)
>
"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 !