Edgar Fuß wrote:
What's the rationale behind calling read_mainconfig() before daemonizing?
So that it can read the configuration before daemonizing. It needs to know which files to load, modules, etc. It also changes UIDs so that any files it writes are correct. And that if there are issues reading the configuration files, they get logged to the correct place.
There's a comment /* Read the configuration files, BEFORE doing anything else. */ suggesting this is intentional.
Yes.
However, during that, mutexes are created via pthread_mutex_init(). To my understanding, fork()ing while holding mutexes (and without intervening via a pthread_atfork() handler) calls for undefined behaviour.
Hmm... it's not *holding* the mutex, it's *creating* it. That should be allowed, IIRC.
Indeed, on NetBSD, I get radiusd: Error detected by libpthread: Invalid mutex. Detected by file [...], line [...], function "pthread_mutex_lock_slow". See pthread(3) for information. unless I use one of the dont_fork options.
Running radiusd -f & works as a workaround.
Also, moving the configuration reading block after the daemonizing block seems to work, but I'm afraid there was a good reason for reading the configuration before doing the fork.
I recall things breaking if we did it the other way around, but that may be from a long time ago. Alan DeKok.