Aaron Stone wrote: > Paul, > > Reading from imapd.c, through server.c, and to pool.c, it looks like the > process path is like this: > > imapd.c: parent process (root) > imapd.c: child process (nobody) > server.c, pool.c: manage more children (more nobodies)
check. That's the idea. > > When you send a HUP to the parent, it does this: > > imapd.c: parent process - Receive the HUP, tell child to restart > imapd.c: child process - Told to restart, kill the children > server.c, pool.c: told to stop, children are killed. > > Then this happens: > > imapd.c: parent process (root) > imapd.c: child process (nobody) -- tries to get a new socket, can't! > > Is that first fork needed to establish the dropped privs before forking > each of the children in the pool? That's correct afaik. You *need* some way to re-establish a new socket as root, and the current setup provides this. > > It would make sense to have the first child simply terminate when it > gets a signal, and then the top level parent restarts everything... > > This fixes it for me: > > --- ../dbmail/imapd.c 2006-02-28 04:15:22.556837664 -0800 > +++ imapd.c 2006-02-28 10:16:50.398784536 -0800 > case 0: > /* child process */ > drop_privileges(config.serverUser, config.serverGroup); > result = StartServer(&config); > trace(TRACE_INFO, "%s,%s: server done, restart = [%d]", > __FILE__, __func__, result); > - > + exit(result); Looks like on-target to me :-). The server code offers many opportunities for redesign (understatement). That's very much a set target for post-2.2 development, as far as I am concerned. But bugs in the current, simple setup should and will be fixed during 2.2's lifetime. I'm still a bit unclear though as to why these problems didn't surface earlier. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl
