At Wed, 07 Apr 2004 12:09:44 +0300,
Kostas Zorbadelos wrote:
>
Today I faced the problem again.
The router sent me accounting with no User-Name and after several
failures of the sql module in accounting section the server stopped
working (no core dump)
> [1 <text/plain; US-ASCII (7bit)>]
>
>
> Hi to everyone.
> I send this a week ago. Has this been answered before or is it not
> clear somehow? I searched the archives and found nothing. If I can
> help giving more information please let me know. I would really like
> to know about this behaviour.
>
> Thanks in advance.
>
> [2 <message/rfc822 (7bit)>]
> To: [EMAIL PROTECTED]
> Subject: Error in sql module causes freeradius to stop functioning
> From: Kostas Zorbadelos <[EMAIL PROTECTED]>
> Date: Thu, 01 Apr 2004 19:20:02 +0300
> Message-ID: <[EMAIL PROTECTED]>
> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6
> (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3
> (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)
> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
>
>
>
> Hello to everyone.
> Yesterday I installed freeradius-0.9.3 on a Solaris 2.7 production
> environment. I use sql module and oracle as my database to store
> accounting. I first try to store the accounting data in the database
> and afterwards I write them in files with the detail module. The
> problem is that sometimes I get data that fail to be inserted in my
> database (wrong size, stupid error) so I see the following in
> radius.log:
>
>
> ...
> Thu Apr 1 15:55:13 2004 : Error: rlm_sql_oracle: execute query failed
> in sql_query: ORA-01401: inserted value too large for column
> Thu Apr 1 15:55:13 2004 : Auth: Login OK: [EMAIL PROTECTED] (from
> client fworks port 352 cli 2221038953)
> Thu Apr 1 15:55:14 2004 : Error: rlm_sql_oracle: execute query failed
> in sql_query: ORA-01401: inserted value too large for column
> Thu Apr 1 15:55:14 2004 : Error: rlm_sql (sql1): failed after re-connect
> Thu Apr 1 15:55:14 2004 : Error: rlm_sql: Couldn't insert SQL
> accounting STOP record - ORA-01401: inserted value too large for column
> Thu Apr 1 15:55:18 2004 : Error: rlm_sql_oracle: execute query failed
> in sql_query: ORA-01401: inserted value too large for column
> Thu Apr 1 15:55:18 2004 : Error: rlm_sql_oracle: execute query failed
> in sql_query: ORA-01401: inserted value too large for column
> Thu Apr 1 15:55:18 2004 : Error: rlm_sql (sql1): failed after re-connect
> Thu Apr 1 15:55:18 2004 : Error: rlm_sql: Couldn't insert SQL
> accounting STOP record - ORA-01401: inserted value too large for column
> Thu Apr 1 15:55:21 2004 : Auth: Login OK: [EMAIL PROTECTED] (from
> client fworks port 0 cli 2104131605)
> ...
>
>
> The error is very clear and I found the problem data. As I can
> understand,
> when a query fails, the sql module will try to execute the alternative
> query (if it exists) and if this also fails it reconnects to the db
> and tries one more time. Is this correct?
> Anyway, the radius server keeps servicing other requests and after a
> few such failures, the whole server stops functioning!
> Is this a correct behaviour? Shouldn't the server keep working servicing
> other requests? Is there some sort of threshold of errors after which
> the server stops functioning? Should we consider that a bug? (at first
> sight it seems this way)
>
>
>
> My configuration regarding accounting follows below.
>
> # Pre-accounting. Decide which accounting type to use.
> #
> preacct {
> preprocess
>
> #
> # Look for IPASS-style 'realm/', and if not found, look for
> # '@realm', and decide whether or not to proxy, based on
> # that.
> #
> # Accounting requests are generally proxied to the same
> # home server as authentication requests.
> # realmslash
> suffix
>
> #
> # Read the 'acct_users' file
> files
> }
>
> #
> # Accounting. Log the accounting data.
> #
> accounting {
> #
> # Ensure that we have a semi-unique identifier for every
> # request, and many NAS boxes are broken.
> acct_unique
>
> #
> # Create a 'detail'ed log of the packets.
> # Note that accounting requests which are proxied
> # are also logged in the detail file.
> # detail
> # daily
>
> # unix # wtmp file
>
> #
> # For Simultaneous-Use tracking.
> #
> # Due to packet losses in the network, the data here
> # may be incorrect. There's little we can do about it.
> # radutmp
> # sradutmp
>
> # Return an address to the IP Pool when we see a stop record.
> # main_pool
> # see acct_users file
> Acct-Type SQL1{
> sql1
> detail
>
> }
> }
>
> The acct_users file:
>
>
> DEFAULT Acct-Type := SQL1
>
>
> Thank you in advance.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
