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]
