]] 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 SIGHUP freeradius would be much more invasive.
|
| Use the "radmin" tool. You can create a tool which causes the server
| to reread *just* the passwd module.
|
| $ radmin
| radmin> hup passwd
I guess that could work, yes.
| > For those that have 1 kpps, just add caching, which I think is there
| > already?
|
| Sure. But the server has to work for *everyone*. Having it crash
| occasionally for others because you don't want to HUP it is not nice.
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 them set it to a
bigger value, they get caching, but have to reload the module when the
file is updated. Everybody is then happy.
It seems like there is still a race condition even with your fix, since
two threads might be executing the
if (ht->fp) {
statement at the same time, leading both to close the file. So your fix
has narrowed the race, but not eliminated it.
Regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
