Re: /etc/init.d/opendkim fails to start opendkim when run over ssh with a pseudo-tty

From: Sam Umbach <sumbach_at_gmail.com>
Date: Sun, 17 Apr 2011 23:11:45 -0400

No luck with that idea. I believe the parent process exits which
leads to the shell exiting and sending sighup to the child process.

On Sun, Apr 17, 2011 at 11:07 PM, Sam Umbach <sumbach_at_gmail.com> wrote:
> This may be related to the file descriptors after all.  It appears
> that the ssh connection will not shut down until stdin/out/err are
> closed by the remote process (either by explicitly closing them or the
> process terminating).  It may be sufficient to move the setsid() above
> the dup2() calls.
>
> -Sam
>
>
> On Sun, Apr 17, 2011 at 10:43 PM, Sam Umbach <sumbach_at_gmail.com> wrote:
>> The problem is not related to the file descriptors at all.  Here's the
>> sequence of events:
>>
>> * connection with ssh established
>> * pty allocated
>> * shell started on pty
>> * /etc/init.d/opendkim start executed, starting the parent process on the pty
>> * parent calls fork(), creating the child process
>> * parent process exits
>> * shell exits
>> * ssh connection is torn down, pty deallocated
>> * child process is still part of the session associated with the pty,
>> receives sighup, and terminates
>>
>> This is a race condition.  If the child process gets far enough to run
>> setsid() before the pty is deallocated, the child process lives on.
>> Unfortunately, the child process doesn't get this far in some
>> percentage of attempts, which is why launching the daemon over ssh
>> with a pty sometimes works and sometimes fails.
>>
>> I see a few ways out:
>> * parent process does not exit until the child has run setsid().  This
>> could be indicated by the child sending the parent process a signal.
>> * parent process calls setsid() before fork() -- will not work if the
>> parent process is the session leader, probably not a good solution
>> * parent process ignores sighup before fork().  There is a small
>> possibility that the parent process would miss a sighup signal, but
>> since the parent terminates shortly after the fork() call, this
>> shouldn't be a problem.
>>
>> The daemonize code in opendkim is completely in line with all the
>> recommendations I've found, which makes me think this race condition
>> may be an issue for many daemons.  I can't be the first person to run
>> into this issue, but I have not yet found another report of it.
>>
>> -Sam
>>
>>
>> On Sun, Apr 17, 2011 at 9:51 PM, Murray S. Kucherawy <msk_at_blackops.org> wrote:
>>> On Sun, 17 Apr 2011, Sam Umbach wrote:
>>>>
>>>> I think I see what's happening now: the parent process exits and the pty
>>>> is torn down before the child process ever starts running (and has a chance
>>>> to close its file handles and call setsid()).  Since the pty is the child
>>>> process' controlling terminal, the child is terminated.
>>>
>>> Since fork() clones all descriptors, why would a close() of them in the
>>> parent (implicit or explicit) cause the tear-down of the pty?  There's still
>>> a descriptor open to it in the child.
>>>
>>>
>>>
>>
>
Received on Mon Apr 18 2011 - 03:12:00 PST