Tollef Fog Heen wrote:
> It's not like those are the only options available. As an example, like
> you said, make the FILE* a local variable in get_next and get_pw_nam.
> For those of us who don't want the caching, let us set the hash table
> size to 0, and all is good, for those who want it, let
]] Alan DeKok
Hi,
| Tollef Fog Heen wrote:
| > Please don't do this. I am using freeradius in a (very) low-volume
| > environment where reading a passwd file once a second (maximum) is not a
| > problem at all. Having the tool that updates the passwd file be run as
| > root or be allowed to SI
Tollef Fog Heen wrote:
> Please don't do this. I am using freeradius in a (very) low-volume
> environment where reading a passwd file once a second (maximum) is not a
> problem at all. Having the tool that updates the passwd file be run as
> root or be allowed to SIGHUP freeradius would be much m
]] Alan DeKok
| Tollef Fog Heen wrote:
| > yes, this works around this specific crash. However, must all modules
| > be written in a thread-safe fashion?
|
| Yes.
Ok.
| > If so, shouldn't rlm_passwd rather
| > be using a mutex to ensure the file pointer isn't accessed from multiple
| > thr
Tollef Fog Heen wrote:
> yes, this works around this specific crash. However, must all modules
> be written in a thread-safe fashion?
Yes.
> If so, shouldn't rlm_passwd rather
> be using a mutex to ensure the file pointer isn't accessed from multiple
> threads at the same time?
Instead, it
]] Alan DeKok
Hi,
| Josip Rodin wrote:
| > I'm forwarding this to the upstream author. Alan, does this sound
| > familiar?
|
| Nope. After a quick look through the code, it might be fixed by this:
|
|
http://github.com/alandekok/freeradius-server/commit/f691b0ec7d4c92919bdd4dc81e8a86b211c0
Josip Rodin wrote:
> I'm forwarding this to the upstream author. Alan, does this sound
> familiar?
Nope. After a quick look through the code, it might be fixed by this:
http://github.com/alandekok/freeradius-server/commit/f691b0ec7d4c92919bdd4dc81e8a86b211c00832
Alan DeKok.
--
To UNSUBS
On Sat, Dec 05, 2009 at 09:45:29AM +0100, Tollef Fog Heen wrote:
> Package: freeradius
> Version: 2.0.4+dfsg-8~lenny3
> Severity: normal
>
> I'm seeing periodical segfaults in rlm_passwd on lenny. The backtrace
> is as follows:
>
> (gdb) c
> Continuing.
>
> Program received signal SIGSEGV, Segm
Package: freeradius
Version: 2.0.4+dfsg-8~lenny3
Severity: normal
I'm seeing periodical segfaults in rlm_passwd on lenny. The backtrace
is as follows:
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x42045950 (LWP 21769)]
0x7fdeaa28cadb in _IO_
9 matches
Mail list logo
