rlm_sql: zero session length

Josip Almasi joe at vrspace.org
Mon Jun 17 18:05:20 CEST 2013


Arran Cudbard-Bell wrote:
>
> On 17 Jun 2013, at 13:49, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
>
>>
>>> Why is this if statement there anyway, some buggy NASes?
>>
>> Almost certainly.
>>
>>> If so, why not just let user handle it in unlang?
>>
>> The rlm_sql module was written before unlang, so that's why the code is there.
>>
>>> IMHO that needs to be removed, or if written for a good reason, made configurable. With rfc-compliant default:)
>>
>>
>> I'll remove it. It's easy enough to do the check in unlang.
>
> It's already gone in 3.0, and you can disable it if you build from source in 2.x.x.
>
> https://github.com/FreeRADIUS/freeradius-server/blob/v2.x.x/src/modules/rlm_sql/rlm_sql.c#L1365
>
> It should probably be left as is for 2.2.1 for users which rely on this behaviour.

Thanks.

In the meantime, I've analyzed what I have.
Including 2 and 3 source.
And the catch is, I should never ever get that warning, because it activates only 'if (numaffected < 1)'.
IOW, when update is executed, but no rows were updated.

I have 8% sessions with the same starttime and stoptime.
And of those, 0.13% gave us 'zero session length' warning.

Turned on sqltrace, and I do see insert for start packet first, then update for stop.
One right after another, amongst all other requests.
But does that mean insert was executed first, and then update?
I think it was only scheduled to execution in that order.
Local scheduler or a database hickup might delay first query just a few milliseconds too long...

Wonders of parallelization;)

Regards...


More information about the Freeradius-Devel mailing list