Jeroen van Wolffelaar wrote: > On Fri, Mar 23, 2007 at 05:30:02PM -0700, Steve Langasek wrote: > >> Frankly, though, the init script has a *lot* of bad code that's trying to >> second-guess start-stop-daemon in ways that it shouldn't. The right way to >> fix this is to kill off all of this extra code, let s-s-d what it's designed >> to, and fix imapproxyd to not bail out with an error *after* it's returned >> control to the parent process... >> > > Right, except that I tried that, and it failed. > > s-s-d's coverage is unfortunately not good enough: #416179 -- making the > s-s-d --backround --pid-file workaround useless in this case :( > > I see three options, all of them suck: > (1) fix s-s-d (no way one week before release), > (2) fix pidfile-writing imapproxy (ugh, but doable, and arguably the > best longtime solution), > As in "save the recycler thread's PID instead of any other" ?
I already have a version which daemonizes as late as possible (i.e. just before launching threads). It does help a bit in the sense that imapproxy will abort execution before dettaching from the parent (s-s-d in this case), but not more. > (3) give up and revert to the sarge "killall imapproxyd" way of stopping > the daemon > > The current way in this init.d script is worse than the killall > imapproxyd thingy, it attempts to kill just one (random) instance of > imapproxyd in a very special way (by first writing some found-via-ps PID > to the pidfile and then using kill-by-pid...) But anyway it plainly > fails at this too. > Unfortunately, yes. This initscript has become a pile of patches one of top of the other. A rewrite I have done (reverting to the new LSB-compliant /etc/init.d/skeleton) doesn't work much better, either. In fact, it is unable to even start imapproxy as it is right now [launching 'manually' does work] > As attachment, my NMU patch which would have fixed this whole mess if > not for #416179. The biggest part of it is still applicable for the > no-op behaviour of start & stop when already started/stopped, and it > fixes pid-file-removal. > > I think the best way forward would be to go for (2). > If you elaborate a bit more on this, I can get it done tonight, I think. Otherwise, please feel free to contribute whatever you see fit. My current set of changes just move the daemonization code into a function of its own and call it just before pthread_create. Looking forward to your soon response, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]