Re: postauth required?
On Wed, 22 Oct 2003 09:13:58 +0100 Graeme Hinchliffe <[EMAIL PROTECTED]> wrote: > > Graeme Hinchliffe <[EMAIL PROTECTED]> wrote: > > > The radiusd runs happily. mysqldump starts and radiusd complains > > > about unresponsive children, the number of threads increases until > > > the mysqldump finishes, at which point the number of threads begins > > > to drop. The no of threads gets to about 20 (initial start value is > > > 5).. at which point the daemon locks up and consumes lots of CPU. > > > It has to be kill -9'd to stop and then restart. > > > > You're hitting a border case in the server, where it doesn't behave > > well. Using huge amounts of CPU is bad, but when the MySQL db > > disappears entirely (due to the mysqldump), you've guaranteed that the > > server can't process any more requests. > > It doesn't dissapear, just is unwritable, and perhaps slowed down. When I have been > watching the logs as the process is run, I see authentication requests continuing, > along with unresponcive child processes. When the dump finishes there is a burst of > radacct data/errors and then the radiusd failes and goes into it's unresponsve state. I have just run a test again this morning with the 0.9.2 latest from CVS (as of yesterday) and got the following in the logs: Wed Oct 22 09:06:41 2003 : Error: rlm_sql_mysql: MYSQL Error: Cannot get result Wed Oct 22 09:06:41 2003 : Error: rlm_sql_mysql: MYSQL Error: Wed Oct 22 09:06:41 2003 : Error: rlm_sql_mysql: MYSQL Error: No Fields Wed Oct 22 09:06:41 2003 : Error: rlm_sql_mysql: MYSQL error: Wed Oct 22 09:06:41 2003 : Info: rlm_sql_mysql: Starting connect to MySQL server for #28 Wed Oct 22 09:06:41 2003 : Error: rlm_sql_mysql: MYSQL Error: Cannot get result Wed Oct 22 09:06:41 2003 : Error: rlm_sql_mysql: MYSQL Error: Wed Oct 22 09:06:41 2003 : Error: rlm_sql_mysql: MYSQL Error: No Fields Wed Oct 22 09:06:41 2003 : Error: rlm_sql_mysql: MYSQL error: Wed Oct 22 09:06:41 2003 : Info: rlm_sql_mysql: Starting connect to MySQL server for #13 Wed Oct 22 09:06:41 2003 : Error: Assertion failed in modcall.c, line 65 At which point all freeradius threads died. The database was still there, just under heavy load and unwritable. -- - Graeme Hinchliffe (BSc) Core Team Member Zen Internet (http://www.zen.co.uk) ICQ 3842605 (link) Direct: 0845 058 9074 Main : 0845 058 9000 Fax : 0845 058 9005 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: postauth required?
> Graeme Hinchliffe <[EMAIL PROTECTED]> wrote: > > The radiusd runs happily. mysqldump starts and radiusd complains > > about unresponsive children, the number of threads increases until > > the mysqldump finishes, at which point the number of threads begins > > to drop. The no of threads gets to about 20 (initial start value is > > 5).. at which point the daemon locks up and consumes lots of CPU. > > It has to be kill -9'd to stop and then restart. > > You're hitting a border case in the server, where it doesn't behave > well. Using huge amounts of CPU is bad, but when the MySQL db > disappears entirely (due to the mysqldump), you've guaranteed that the > server can't process any more requests. It doesn't dissapear, just is unwritable, and perhaps slowed down. When I have been watching the logs as the process is run, I see authentication requests continuing, along with unresponcive child processes. When the dump finishes there is a burst of radacct data/errors and then the radiusd failes and goes into it's unresponsve state. -- - Graeme Hinchliffe (BSc) Core Team Member Zen Internet (http://www.zen.co.uk) ICQ 3842605 (link) Direct: 0845 058 9074 Main : 0845 058 9000 Fax : 0845 058 9005 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: postauth required?
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote: > The radiusd runs happily. mysqldump starts and radiusd complains > about unresponsive children, the number of threads increases until > the mysqldump finishes, at which point the number of threads begins > to drop. The no of threads gets to about 20 (initial start value is > 5).. at which point the daemon locks up and consumes lots of CPU. > It has to be kill -9'd to stop and then restart. You're hitting a border case in the server, where it doesn't behave well. Using huge amounts of CPU is bad, but when the MySQL db disappears entirely (due to the mysqldump), you've guaranteed that the server can't process any more requests. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: postauth required?
> That's bad. Try running it like radiusd -xxx and send back the results. It would > be nice if you upgraded to 0.9.2 first though. 0.9.2 ? where is that? I am using code from the CVS. I'll see if I can get the same thing to happen with -xxx > > I always thought that the lock would be to stop writes to the db? not reads? > > I think it's a global lock though i am not sure. In any case you are using > radiusd for accounting right (which means writing to the db)? true. -- - Graeme Hinchliffe (BSc) Core Team Member Zen Internet (http://www.zen.co.uk) ICQ 3842605 (link) Direct: 0845 058 9074 Main : 0845 058 9000 Fax : 0845 058 9005 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: postauth required?
On Tue, 21 Oct 2003, Graeme Hinchliffe wrote: > > > When the database is used heavily by another process freeradius eats > > > loads of CPU, becomes unresponsive and eventually just dies. This only seems > > > to happen when another process (such as mysql_dump) is ran on the database. > > > > radiusd should never die. Check for any core dumps. In any case if you are using > > mysqldump it will acquire a global lock on the db and not allow the radiusd sql > > queries to run. As a result the radiusd process will become unresponsive (though > > it should not eat loads of CPU) > > That fits with what happens, I think I got the order slightly out. To be more > precises: > > The radiusd runs happily. mysqldump starts and radiusd complains about > unresponsive children, the number of threads increases until the mysqldump > finishes, at which point the number of threads begins to drop. The no of > threads gets to about 20 (initial start value is 5).. at which point the > daemon locks up and consumes lots of CPU. It has to be kill -9'd to stop and > then restart. That's bad. Try running it like radiusd -xxx and send back the results. It would be nice if you upgraded to 0.9.2 first though. > > I always thought that the lock would be to stop writes to the db? not reads? I think it's a global lock though i am not sure. In any case you are using radiusd for accounting right (which means writing to the db)? > > -- > - > Graeme Hinchliffe (BSc) > Core Team Member > Zen Internet (http://www.zen.co.uk) > > ICQ 3842605 (link) > > Direct: 0845 058 9074 > Main : 0845 058 9000 > Fax : 0845 058 9005 > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- Kostas Kalevras Network Operations Center [EMAIL PROTECTED] National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: postauth required?
> > When the database is used heavily by another process freeradius eats > > loads of CPU, becomes unresponsive and eventually just dies. This only seems > > to happen when another process (such as mysql_dump) is ran on the database. > > radiusd should never die. Check for any core dumps. In any case if you are using > mysqldump it will acquire a global lock on the db and not allow the radiusd sql > queries to run. As a result the radiusd process will become unresponsive (though > it should not eat loads of CPU) That fits with what happens, I think I got the order slightly out. To be more precises: The radiusd runs happily. mysqldump starts and radiusd complains about unresponsive children, the number of threads increases until the mysqldump finishes, at which point the number of threads begins to drop. The no of threads gets to about 20 (initial start value is 5).. at which point the daemon locks up and consumes lots of CPU. It has to be kill -9'd to stop and then restart. I always thought that the lock would be to stop writes to the db? not reads? -- - Graeme Hinchliffe (BSc) Core Team Member Zen Internet (http://www.zen.co.uk) ICQ 3842605 (link) Direct: 0845 058 9074 Main : 0845 058 9000 Fax : 0845 058 9005 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: postauth required?
On Tue, 21 Oct 2003, Graeme Hinchliffe wrote: > Hiya > Will not having entries for postauth in the sql configuration cause > issues? I am still using the sql config from freeRADIUS 0.9.0 with the cvs > version of 0.9.1 No it won't > > When the database is used heavily by another process freeradius eats > loads of CPU, becomes unresponsive and eventually just dies. This only seems > to happen when another process (such as mysql_dump) is ran on the database. radiusd should never die. Check for any core dumps. In any case if you are using mysqldump it will acquire a global lock on the db and not allow the radiusd sql queries to run. As a result the radiusd process will become unresponsive (though it should not eat loads of CPU) > > I am examining configuration files to see if there is anything I have > overlooked. > > -- > - > Graeme Hinchliffe (BSc) > Core Team Member > Zen Internet (http://www.zen.co.uk) > > ICQ 3842605 (link) > > Direct: 0845 058 9074 > Main : 0845 058 9000 > Fax : 0845 058 9005 > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- Kostas Kalevras Network Operations Center [EMAIL PROTECTED] National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
postauth required?
Hiya Will not having entries for postauth in the sql configuration cause issues? I am still using the sql config from freeRADIUS 0.9.0 with the cvs version of 0.9.1 When the database is used heavily by another process freeradius eats loads of CPU, becomes unresponsive and eventually just dies. This only seems to happen when another process (such as mysql_dump) is ran on the database. I am examining configuration files to see if there is anything I have overlooked. -- - Graeme Hinchliffe (BSc) Core Team Member Zen Internet (http://www.zen.co.uk) ICQ 3842605 (link) Direct: 0845 058 9074 Main : 0845 058 9000 Fax : 0845 058 9005 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
