cannot get core dump of crashing freeradius

2010-04-16 Thread Jakob Hirsch
Hi, we have freeradius 2.1.8 running on a couple of servers and are very happy with it. But every few days FR crashes on one of the servers (a random one, not always the same). The load is significant (average 150 requests/s per server, 400/s peak) but sureley not too high. So everything seems to

Re: cannot get core dump of crashing freeradius

2010-04-19 Thread Jakob Hirsch
Alan DeKok, 2010-04-16 12:05: Often 'root' can't core dump, and programs that change uid can't core dump. It's hard to know what's going on with the OS. ok, I digged deeper into this and made some tests: - no core dump with kill -11 - /proc/sys/fs/suid_dumpable is 0, set it to 1 and

Re: cannot get core dump of crashing freeradius

2010-04-19 Thread Jakob Hirsch
Alan Buxey, 2010-04-19 16:43: Maybe the info about /proc/sys/fs/suid_dumpable should be added to doc/bugs... to quote the man page: /proc/sys/fs/suid_dumpable (since Linux 2.6.13) ... i dont think this got enough coverage in most information outlets..in fact 2.6.13 has been around

Re: cannot get core dump of crashing freeradius

2010-04-20 Thread Jakob Hirsch
Alan DeKok, 2010-04-20 10:54: So after some debugging I got to the root cause of this: The process's dumpable flag is reset every time the UID is changed. FR does this several times with fr_suid_up() and fr_suid_down() after switch_users() is run, e.g. in listen_bind(). So I guess we have to

Re: cannot get core dump of crashing freeradius

2010-04-26 Thread Jakob Hirsch
Alan DeKok, 04/20/2010 06:21 PM: btw, I wonder why is prctl() is not called when debug_flag is set. I would have thought that one would want to get a core dump especially when running in debug mode. It doesn't switch UIDs when in debug mode. So it inherits whatever AFAICS it does when

Change of logging behaviour in 2.1.9 (was: Version 2.1.9 has been released)

2010-06-17 Thread Jakob Hirsch
Hi, Alan DeKok, 2010-05-24 12:28: * re-open log file after HUP. Closes bug #63. Since the update to 2.1.9 a new log file is _only_ opened on HUP. Is this behaviour intended? Previously we just let logrotate rename the old logfile and freeradius created a new radius.log. I'm aware that it is

Re: Change of logging behaviour in 2.1.9

2010-06-18 Thread Jakob Hirsch
Bjørn Mork, 2010-06-17 18:28: * re-open log file after HUP. Closes bug #63. FWIW we have been HUPing the server from a daily, unattended process with FR 2.1.8 since it was released (we need it to rotate log files Ok. That's what we are doing now, too. After all, other daemons (apache,

Re: Change of logging behaviour in 2.1.9

2010-06-19 Thread Jakob Hirsch
On 18.06.2010 17:48, Alan DeKok wrote: I just wonder why there is such a change in a patch level update. And what the above mentioned bug was about... The bug was that it *wasn't* re-opening the log file on HUP. Since this is expected behavior, it needed to be fixed. But it was already

Re: Pre release of 2.1.10

2010-09-16 Thread Jakob Hirsch
Hi, Alan DeKok, 2010-09-06 13:58: It's been a few weeks since the last pre release of 2.1.10. I've put another one up on the web at: I tried it, mainly to get rid of the random segfaults we get every few days (bug #35). Unfortunately, last night it a crashed on one machine (after running

Re: regexp matches are sensitive to position in check items

2008-04-04 Thread Jakob Hirsch
Quoting Phil Mayers: Basically, this works in hints: DEFAULT NAS-Port-Id =~ (.+):(.+), NAS-Port !* ANY NAS-Port = `%{expr:1000*%{1} + %{2}}`, Fall-Through = Yes ...but this does not: DEFAULT NAS-Port !* ANY, NAS-Port-Id =~ (.+):(.+) NAS-Port = `%{expr:1000*%{1} +

Re: regexp matches are sensitive to position in check items

2008-04-05 Thread Jakob Hirsch
Phil Mayers wrote: This is caused by an apparent bug in src/main/valuepair.c. Line 287 should say continue; instead of return 0;. ... I'll be happy to provide a patch, I just don't know if Alan will release any further 1.1.x version. Does the same bug not exist in 2.0? I think not. I took

Re: Version 2.1.12 has been released

2011-10-04 Thread Jakob Hirsch
Alan DeKok, 2011-09-30 16:33: * Added support for PCRE from Phil Mayers Sorry for not stepping up before, but it seems to me that this only went into the master, not in the 2.1.x branch. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Blocking Interim-Update Accounting-Requests

2007-04-21 Thread Jakob Hirsch
Hi, is it possible to filter out accounting requests with an Acct-Status-Type of Interim-Update? rlm_attr_filter works obviously only when we are a proxy, and rlm_files with this acct_users changed nothing: DEFAULT Acct-Status-Type == Interim-Update, Auth-Type := Reject DEFAULT

Re: Blocking Interim-Update Accounting-Requests

2007-04-22 Thread Jakob Hirsch
Alan DeKok wrote: If you are trying to log some packets and not others, then do conditional logging. e.g. if packet is type I want to log That's exactly what I want. And it works now with using Acct-Type. Thanks for that! For the list archive (using version 1.1.4): acct_users: DEFAULT

Re: FreeRADIUS 2.0.0-pre2 has been released

2007-09-13 Thread Jakob Hirsch
Quoting Alan T DeKok: Hi, After much waiting, 2.0.0-pre2 has been released. It contains MAJOR Wow, looks very nice! The unlang will probably will allow us to throw away some of our own modules. As I understand the virtual servers, it is possible to have all vservers listen to the same

Re: FreeRADIUS 2.0.0-pre2 has been released

2007-09-14 Thread Jakob Hirsch
Quoting Alan DeKok: As I understand the virtual servers, it is possible to have all vservers listen to the same ip/port socket, but have different client configurations. Is that right? Hmm... hadn't thought of doing it that way. It could be possible. Meaning try it and get back to list

Re: Version 1.1.8 has been released

2009-09-21 Thread Jakob Hirsch
Hi, Alan DeKok, 2009-09-09 14:54: We have released version 1.1.8 to fix an issue with the handling of Tunnel-Password. This is the same issue that was found in version This sounds harmless for most people, I guess, or at least for us, as we don't use Tunnel-Password. But reading

operator !* in update {}

2009-11-13 Thread Jakob Hirsch
Hi, according to unlang: !* Delete all occurances of the named attribute, no matter what the value. but when I want to use it like that: post-auth { Post-Auth-Type REJECT { update reply { Idle-Timeout !* 0

Re: operator !* in update {}

2009-11-13 Thread Jakob Hirsch
Alexander Clouter, 2009-11-13 13:03: /etc/freeradius2//sites/ui.site.conf[205]: Parse error after Idle-Timeout I get the same thing and kept meaning to file a bug report. I opted as a quick hack: update reply { Blar -= %{reply:Blar} } Thanks, that's clever! Also thanks to