forking new process when calling gnutls_global_init() function

[Haidar Habib]

Hi Werner,

I have done some debugging on the child process. Following is the
output of bactrace(bt) of functions call by it.
Pls look into this if this helps.


#0  0xc0201020 in _write_sys+0x10 () from /usr/lib/libc.2
#1  0xc020d13c in write+0xc4 () from /usr/lib/libc.2
#2  0xc6478130 in start_gatherer+0x320 () from /usr/local/lib/libgcrypt.sl.13
#3  0xc64784f4 in _gcry_rndunix_gather_random+0x148 ()
   from /usr/local/lib/libgcrypt.sl.13
#4  0xc642e128 in read_random_source+0xe0 ()
   from /usr/local/lib/libgcrypt.sl.13
#5  0xc642dc04 in random_poll+0x58 () from /usr/local/lib/libgcrypt.sl.13
#6  0xc642d6bc in read_pool+0x308 () from /usr/local/lib/libgcrypt.sl.13
#7  0xc642c6cc in gcry_randomize+0x1b0 () from /usr/local/lib/libgcrypt.sl.13
#8  0xc5b46fa0 in gc_pseudo_random+0x38 ()
   from /usr/local/lib/libgnutls-extra.sl.13
#9  0xc6357c84 in gnutls_global_init+0x42c ()
   from /usr/local/lib/libgnutls.sl.13

Actually my concern is why the child process is visible in HPUX os and
not in LINUX. Is this because in HPUX there is no /dev/random device
defined or due to any other reason.
For us it is not a good option to have a child process wtih our actual process.
So can you pls provide some fix so that no child process is present there .


Regards,
Haidar

On Wed, Feb 20, 2008 at 11:27 PM, Werner Koch <wk at gnupg.org> wrote:
> On Wed, 20 Feb 2008 14:38, h.habib at gmail.com said:
>
> > lets say our process name is dfn_tls. When we run this process and then
> >  do ps -aef we get the following output.
> >
> >   haidar 24069 24068  0 17:53:54 ttyp1     0:00 ./dfn_tls clientDfn.cfg
> >   haidar 24068 23117  0 17:53:51 ttyp1     0:04 ./dfn_tls clientDfn.cfg
>
> Okay that is useful.  I have not looked at the code for a long time, so
> please excuse that I didn't mentioned it right away.  What libgcrypt
> with rndunix does is to chreate a child process which runs an the actual
> entropy gathering (spawing system utilities).  The child communicates
> via a pipe with the parent and is controlled by the parent reading from
> the child.  Thus after the parent read enough (i.e. got enough entropy),
> the child (the entropy gatherer loop) will eventually wait in a write
> call until the parent reads again from it.
>
> So now if you kill that child and libgcrypt (the parent) needs to get
> more entropy it sits in a read without the other other end connected and
> thus gets an EPIPE.  You should see a
>
>  "reading from gatherer pipe failed: %s"
>
> error message.  Of course we could restart the gatherer process but as
> it should never terminate in the first place there is no point in
> starting it again.  libgcrypt will instead hang in its random generator
> because it is not able to load new entropy into its pool.
>
> If there is a real problem, you should either fire up a debugger or
> sprinkle more debug printfs into it.
>
>
>
>
> Shalom-Salam,
>
>   Werner
>
>
>
> --
> Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.
>
>