forking new process when calling gnutls_global_init() function
Haidar Habib
h.habib at gmail.com
Mon Feb 25 13:56:53 CET 2008
Thanks for all your suggestions. Finally I am able to do away with
this problem by installing random generator software KRNG11i in my
HPUX machine. This software created /dev/random and now no child
process is created.
Thanks
Regards,
Haidar Habib
On Thu, Feb 21, 2008 at 6:55 PM, Simon Josefsson <simon at josefsson.org> wrote:
> "Haidar Habib" <h.habib at gmail.com> writes:
>
> > 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
>
> This looks consistent with what Werner described how it is intended to
> work.
>
> > 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.
>
> Yes, that's the reason. On linux, cipher/rndlinux.c is used, which is
> very different from cipher/rndunix.c which is used under HPUX.
>
> > 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 .
>
> EGD was suggested, and if it didn't work, the only other option is to
> modify libgcrypt to do something else -- you could check with the HPUX
> documentation if there isn't a entropy API somewhere.
>
> I wouldn't consider forking a child process to be a problem though. It
> is how libgcrypt was intended to work on generic unix systems. If you
> could describe in more detail why you think that is a problem (memory
> usage?), maybe that problem could be fixed.
>
> /Simon
>
>
>
> >
> > 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.
> >>
> >>
>
More information about the Gcrypt-devel
mailing list