forking new process when calling gnutls_global_init() function
h.habib at gmail.com
Thu Feb 21 12:51:48 CET 2008
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 ()
#4 0xc642e128 in read_random_source+0xe0 ()
#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 ()
#9 0xc6357c84 in gnutls_global_init+0x42c ()
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 .
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.
> Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
More information about the Gcrypt-devel