[RADIATOR] Howto investigate a "dropped connection" problem with Radiator and Postgres on a local connection?
e.lohmann at ic3s.de
Tue Oct 22 08:27:06 CDT 2013
In my understanding only <AuthBy External> is a fork right?
Then we don't fork.
Am 22.10.2013 10:18, schrieb Eike Lohmann:
> Hi Heikki,
> we use <AuthBy SQL> one for authentication and another <AuthBy SQL> for
> accounting, a never used <AuthBy File> and some <AuthBy Group>'s.
> Is this our Problem?
> Do you know the default value of "InactiveDestroy" we don't set it in our
> postgres config files.
> Never seen a retry from Radiator and we have missing START, ALIVE and STOP
> Accounting Records in ~1% from 100.000.
> Thanks for your help.
> Am 21.10.2013 21:11, schrieb Heikki Vatiainen:
>> On 10/18/2013 04:15 PM, Eike Lohmann wrote:
>>> we have a problem between radiator 4.9 and postgresql 9.1 on many
>>> machines and have had this problem with Radiator 4.7, 4.8 and
>>> postgressql 8.3, 8.4.
>>> The Problem occurs from 100k Session at a rate of less ~1% while an
>>> update or insert statement from Radiator, the connection is local!
>> Hello Eike,
>> I'd think this is not a SSL problem since you see it with non-SSL
>> connections too. Also, since you are using a local connection, the
>> networking problems should not be the cause.
>> Do you use fork? Please see this link to Pg module documentation which
>> mentions the error message you see:
>> Do you for example, fork for some slow AuthBys?
>> The postgresql log entry you have quoted below might be from the retry
>> Radiator does. If execute fails, it will retry and the PostgreSQL log
>> entry might be from the retry, not from the failed initial execute.
>> Retrying execute should also mean that even if you do get the error, the
>> query will succeed with the retry.
>>> Logfile Radiator with SSL:
>>> "Wed Feb 22 09:43:45 2012: ERR: Execute failed for 'select
>>> d.DEVICELOGINPASSWORD, d.DEVICEIP from device d where d.DEVICELOGINNAME
>>> = 'xy' and d.DEVICEENABLED = 'Y'': SSL-Error: sslv3 alert bad record mac"
>>> Logfile Postgres with SSL:
>>> 2012-02-22 09:37:09 CET LOG: 08P01: SSL-Fehler: decryption failed or bad
>>> record mac
>>> 2012-02-22 09:37:09 CET ORT: secure_read, be-secure.c:277
>>> 2012-02-22 09:37:09 CET LOG: 08006: konnte Daten vom Client nicht
>>> empfangen: Die Verbindung wurde vom Kommunikationspartner
>>> zurückgesetzt(no data from client, connection was reset)
>>> 2012-02-22 09:37:09 CET ORT: pq_recvbuf, pqcomm.c:769
>>> 2012-02-22 09:37:09 CET LOG: 08P01: unerwartetes EOF auf
>>> Client-Verbindung(unexpected EOF from client)
>>> 2012-02-22 09:37:09 CET ORT: SocketBackend, postgres.c:332
>>> After debugging this problem we changed the connection method from IP to
>>> Socket without ssl and get the same problem but now without a ssl error
>>> Logfile Radiator Soket:
>>> "Wed Feb 22 11:24:46 2012: ERR:|server closed the connection
>>> unexpectedly This probably means the server terminated abnormally before
>>> orwhileprocessing the request.|"
>>> Logfile Postgres Soket:
>>> 2012-02-22 11:24:46 CET LOG: 00000: Verbindung empfangen:
>>> Host=[local](incomming connection)
>>> 2012-02-22 11:24:46 CET ORT: BackendInitialize, postmaster.c:3279
>>> 2012-02-22 11:24:46 CET LOG: 00000: Verbindung authorisiert:
>>> Benutzer=radius Datenbank=radius (connection authorized)
>>> 2012-02-22 11:24:46 CET ORT: BackendInitialize, postmaster.c:3357
>>> 2012-02-22 11:24:46 CET LOG: 00000: Dauer: 2.930 ms (duration)
>>> Sorry for the old and german logentries, but maybe you have some ideas
>>> how to investigate this problem with more details.
>>> Thanks, Eike
>>> radiator mailing list
>>> radiator at open.com.au
> radiator mailing list
> radiator at open.com.au
More information about the radiator