Re: [RADIATOR] Howto investigate a dropped connection problem with Radiator and Postgres on a local connection?
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: http://search.cpan.org/~turnstep/DBD-Pg/Pg.pm#InactiveDestroy_%28boolean%29 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. Thanks, Heikki 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 message. 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: 0: 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: 0: 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: 0: 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@open.com.au http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Howto investigate a dropped connection problem with Radiator and Postgres on a local connection?
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: http://search.cpan.org/~turnstep/DBD-Pg/Pg.pm#InactiveDestroy_%28boolean%29 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. Thanks, Heikki 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 message. 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: 0: 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: 0: 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: 0: 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@open.com.au http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Howto investigate a dropped connection problem with Radiator and Postgres on a local connection?
On 10/22/2013 11:18 AM, Eike Lohmann wrote: 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? No, I do not think so. If you do not have Fork option anywhere, or AuthBy EXTERNAL as you noted, the above are fine. With external, forking and FarmSize, (do you have server farm?) one needs to be careful that the process that requested something from the DB is the one that gets the answer. Otherwise the messaging between Radiator processes and the DB gets does not work correctly. Do you know the default value of InactiveDestroy we don't set it in our postgres config files. My understanding it is not set. That is, you need to explicitly set it to true. But if you do not fork, then it should not matter. Never seen a retry from Radiator and we have missing START, ALIVE and STOP Accounting Records in ~1% from 100.000. When it retries you should first see an ERR message about execute failing and then the normal DEBUG level message starting with 'Query to ...'. The DEBUG message is from the retry. Thanks, Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Howto investigate a dropped connection problem with Radiator and Postgres on a local connection?
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: http://search.cpan.org/~turnstep/DBD-Pg/Pg.pm#InactiveDestroy_%28boolean%29 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. Thanks, Heikki 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 message. 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: 0: 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: 0: 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: 0: 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@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Howto investigate a dropped connection problem with Radiator and Postgres on a local connection?
Hi, 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! 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 message. 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: 0: 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: 0: 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: 0: 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@open.com.au http://www.open.com.au/mailman/listinfo/radiator
