fork() after pthread_mutex_init()

[Alan DeKok]

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.