On Sun, Mar 25, 2007 at 05:53:51PM +0200, José Luis Tallón wrote: > 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.
I think the pid of the process right after the second fork in src/main.c is the one you want. imapproxy should have support to write down that process id to a file, for example, to a configurable place (like "pidfile /var/run/imapproxy.pid" in /etc/imapproxy.conf). If that'd be the default too, then it'd "just work", even if the user doesn't upgrade his config. If imapproxy would do that, then the --background and --pid-file options to s-s-d can be dropped, and it'd all just work. If you can implement this minimally, I'll sponsor you, unless some RM tells that even this change would be too intrusive. > > (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] the killall imapproxyd is still the plan B I'd say. > > 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. See above for what I think should be implemented. > 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. I don't understand, but I'm not sure it matters at this point. You might want to send a patch of your current changes to me or so, so that I can understand, but I don't think this is some change to consider right now. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
