RE: Issue reading from detail to sql (buffered-sql virtual server)
Hi - here's the config, it returns this:
+- entering group accounting
rlm_detail: Suppressing writes to detail file as the request was just
read from a detail file.
++[detail_rewrite] returns noop
} # server local_logger
It still stops after the first radclient packet, though. I commented out
'sql_logger1', which is what I use to write to postgres.
---
in radiusd.conf:
detail detail_normal {
detailfile = ${radacctdir}/detail
detailperm = 0600
}
detail detail_forsql {
detailfile = ${radacctdir}/detail_forsql
detailperm = 0600
}
detail detail_rewrite {
detailfile = ${radacctdir}/detail_rewrite
detailperm = 0600
}
--
in sites-available/backend
server backend {
listen {
ipaddr = 127.0.0.1
port = 1813
type = acct
secret = verysekrit
}
preacct {
preprocess
acct_unique
}
accounting {
detail_normal
detail_forsql
}
}
--
in sites-available/local_logger
server local_logger {
listen {
type = detail
filename = ${radacctdir}/detail_forsql
load_factor = 20
}
preacct {
preprocess # I normally comment these out
acct_unique # as when using sql_logger1,it
files # it makes no difference.
}
accounting {
detail_rewrite
# sql_logger1
}
}
Thanks,
Nick Freeman
ihug engineering
-Original Message-
Do you have a *minimal* configuration that can reproduce this? i.e.
read from "detail", log to "detail-x", and send 2 packets with
"radclient".
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Issue reading from detail to sql (buffered-sql virtual server)
Nick Freeman wrote: > Hi, > > The below was added and recompiled with the same result - the virtual server > writing to the database stops at "Ready to process requests." Thanks. I'll take a look at adding some more automated tests to check for this. Do you have a *minimal* configuration that can reproduce this? i.e. read from "detail", log to "detail-x", and send 2 packets with "radclient". Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Issue reading from detail to sql (buffered-sql virtual server)
Hi, The below was added and recompiled with the same result - the virtual server writing to the database stops at "Ready to process requests." Thanks, Nick -- It looks like it isn't noticing that it's finished reading the file. I would suggest going to line 482 of src/main/detail.c, and adding a new line: data->state = STATE_HEADER; if (feof(data->fp) goto cleanup; // added line return 0; If that fixes it, I'll commit it to CVS. if not then the issue is a little more complicated. <>- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Issue reading from detail to sql (buffered-sql virtual server)
Nick Freeman wrote: > However it never deletes or changes the detail.work file - so when I > send a second accounting packet, it will go into the detail file without > a problem (and will be the only packet in the file) but detail.work > seems to be locked with the first packet. No matter how many packets I > send it detail.work always sticks with the first packet, and nothing > ever gets written to the database. It looks like it isn't noticing that it's finished reading the file. I would suggest going to line 482 of src/main/detail.c, and adding a new line: data->state = STATE_HEADER; if (feof(data->fp) goto cleanup; // added line return 0; If that fixes it, I'll commit it to CVS. if not then the issue is a little more complicated. The good news is that 2.0 now has the skeleton of a regression test suite in src/tests. So adding an automated test for this case should be relatively straightforward. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Issue reading from detail to sql (buffered-sql virtual server)
I've done some more digging as to why the database only gets one
update..
With no detail or detail.work file, freeradius will wake up every 1
second to check for creation - when it gets updated, it puts it into the
database fine.
However it never deletes or changes the detail.work file - so when I
send a second accounting packet, it will go into the detail file without
a problem (and will be the only packet in the file) but detail.work
seems to be locked with the first packet. No matter how many packets I
send it detail.work always sticks with the first packet, and nothing
ever gets written to the database.
The problem was originally with 2.0.0, I have tried with the latest CVS
with no luck either.
The end of the debug for the virtual server which does the DB writing is
below, nothing ever shows up after the last line:
rlm_sql (sql_logger1): Reserving sql socket id: 13
rlm_sql_postgresql: Status: PGRES_COMMAND_OK
rlm_sql_postgresql: query affected rows = 1
rlm_sql (sql_logger1): Released sql socket id: 13
++[sql_logger1] returns ok
++[ok] returns ok
} # server local_logger
RTT 38420 delay 153680
Finished request 0.
Going to the next request
Waking up in 0.9 seconds.
Cleaning up request 0 ID 37069 with timestamp +20
Ready to process requests.
Any help would be appreciated, thanks!
Nick
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
s.org] On Behalf Of Nick Freeman
Sent: Wednesday, January 30, 2008 10:06 AM
To: freeradius-users@lists.freeradius.org
Subject: Issue reading from detail to sql (buffered-sql virtual server)
Hi,
I'm trying to get my detail file picked up by multiple virtual servers
and relayed to multiple PostgreSQL backends. The detail file writes
fine, however the detail reader will only ever write one entry to the
Postgres DB when it starts.
The config I have for the virtual server in question is below:
server local_logger {
listen {
type = detail
filename = ${radacctdir}/detail
load_factor = 20
}
preacct {
preprocess
acct_unique
files
}
accounting {
sql_logger1
}
}
I have verified that sql_logger1 isn't the problem, if I put that after
the detail directive in another virtual server data gets written to the
database every time. It looks like my local_logger never picks anything
up (except once on startup). Looking at server starting in debug mode I
see this:
listen {
type = "detail"
listen {
filename = "/var/log/freeradius/radacct/detail"
load_factor = 20
}
}
Is this normal? The listen directive is in the same format as the other
virtual servers but this is the only one which has nested listens in the
server startup.
Thanks in advance,
Nick
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
