Mailing List Archive

I am using gnutls and libgcrypt in my application for using TLS in HP-UX. But when calling gnutls_global_init() function it forking a new process giving following trace
[New process 28026]
warning: reading `r3' register: No data
Detaching after fork from process 28026

Can you please help why this new process is being created and how to avoid this.

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Thu, 14 Feb 2008 08:33, h.habib@gmail.com said:

> I am using gnutls and libgcrypt in my application for using TLS in
> HP-UX. But when calling gnutls_global_init() function it forking a new

Please direct your questions to the gnutls mailing list and not to this
one (which is dedicated to libgcrypt).


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Thanks for ur response. Actually I raised this to gnutls mailing list
but they replied that there is no call to fork in that and asked to
raised this to gcrypt mailing list. So I raised this here.
So pls help if you can in this regard.

Regards,
Haidar Habib

On Feb 15, 2008 11:11 PM, Werner Koch <wk@gnupg.org> wrote:
> On Thu, 14 Feb 2008 08:33, h.habib@gmail.com said:
>
> > I am using gnutls and libgcrypt in my application for using TLS in
> > HP-UX. But when calling gnutls_global_init() function it forking a new
>
> Please direct your questions to the gnutls mailing list and not to this
> one (which is dedicated to libgcrypt).
>
>
> Salam-Shalom,
>
> Werner
>
> --
> Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
>
>



--
With regards,
Md. Haidar Habib
Senior Software Engineer
haidar.habib@aricent.com
Aricent
Gurgaon
Cell- 09350042332

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

The fork is in libgcrypt (rndunix.c), so I think it is an appropriate
question for the libgcrypt list. As far as I understand, there is
nothing we can do to avoid the fork from gnutls.

/Simon

"Haidar Habib" <h.habib@gmail.com> writes:

> Thanks for ur response. Actually I raised this to gnutls mailing list
> but they replied that there is no call to fork in that and asked to
> raised this to gcrypt mailing list. So I raised this here.
> So pls help if you can in this regard.
>
> Regards,
> Haidar Habib
>
> On Feb 15, 2008 11:11 PM, Werner Koch <wk@gnupg.org> wrote:
>> On Thu, 14 Feb 2008 08:33, h.habib@gmail.com said:
>>
>> > I am using gnutls and libgcrypt in my application for using TLS in
>> > HP-UX. But when calling gnutls_global_init() function it forking a new
>>
>> Please direct your questions to the gnutls mailing list and not to this
>> one (which is dedicated to libgcrypt).
>>
>>
>> Salam-Shalom,
>>
>> Werner
>>
>> --
>> Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
>>
>>
>
>
>
> --
> With regards,
> Md. Haidar Habib
> Senior Software Engineer
> haidar.habib@aricent.com
> Aricent
> Gurgaon
> Cell- 09350042332

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Sun, 17 Feb 2008 17:34, simon@josefsson.org said:

> The fork is in libgcrypt (rndunix.c), so I think it is an appropriate
> question for the libgcrypt list. As far as I understand, there is
> nothing we can do to avoid the fork from gnutls.

Ah okay. That is the entropy gatherer as used on HPUX.

Continuing on gcrypt-devel.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Thu, 14 Feb 2008 08:33, h.habib@gmail.com said:

> I am using gnutls and libgcrypt in my application for using TLS in
> HP-UX. But when calling gnutls_global_init() function it forking a new
> process giving following trace
> [New process 28026]
> warning: reading `r3' register: No data
> Detaching after fork from process 28026
>
> Can you please help why this new process is being created and how to avoid this.

On systems with a random device, libgcrypt uses an entropy gatherer
which works by running dozens of system tools to gather stats about the
system. The error message is likely from one of these tools. I don't
know tryhe trace utility but if you can configure it to also show the
exec call, you will see the culprit.

An easier way to debug this is by setting the envvar:

GNUPG_RNDUNIX_DBG=filename

The actual code is cipher/rndunix.c .

A failure of one of the tools is not a real problem. If track it down
we might be able to exclude that tool for a certain version of HPUX.


Shalom-Salam,

Werner



--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Hi Werner,

Thanks for your response.
I have exported the variable and run the application as you suggested
and got the following outful in file.
But I don't know what to infer from this.

Regards,
Haidar

START RNDUNIX DEBUG pid=27534
/bin/vmstat -s contributed 0 bytes, usefulness = 2
/bin/vmstat -c contributed 0 bytes, usefulness = 2
/bin/vmstat -i contributed 0 bytes, usefulness = 1
/usr/bin/last -n 50 contributed 0 bytes, usefulness = 0
/usr/bin/nfsstat contributed 1698 bytes, usefulness = 3
/bin/vmstat -f contributed 47 bytes, usefulness = 0
/bin/ps -el contributed 17179 bytes, usefulness = 5
/bin/ps -A contributed 0 bytes, usefulness = 0
/usr/bin/netstat -s contributed 2566 bytes, usefulness = 5
/usr/bin/netstat -m contributed 34 bytes, usefulness = 1
/bin/netstat -in contributed 253 bytes, usefulness = 1
/usr/bin/w contributed 1330 bytes, usefulness = 1
/usr/bin/iostat contributed 42 bytes, usefulness = 0
/usr/bin/uptime contributed 68 bytes, usefulness = 0
/bin/vmstat contributed 135 bytes, usefulness = 0
/usr/bin/ipcs -a contributed 2214 bytes, usefulness = 1
/usr/sbin/ripquery -nw 1 127.0.0.1 contributed 109 bytes, usefulness = 0
/bin/lpstat -t contributed 65 bytes, usefulness = 0
/etc/arp -a contributed 82 bytes, usefulness = 0
/usr/bin/netstat -n contributed 13987 bytes, usefulness = 6
/usr/bin/df contributed 589 bytes, usefulness = 0
Got 40398 bytes, usefulness = 23




On Feb 18, 2008 2:06 PM, Werner Koch <wk@gnupg.org> wrote:
> On Thu, 14 Feb 2008 08:33, h.habib@gmail.com said:
>
>
> > I am using gnutls and libgcrypt in my application for using TLS in
> > HP-UX. But when calling gnutls_global_init() function it forking a new
> > process giving following trace
> > [New process 28026]
> > warning: reading `r3' register: No data
> > Detaching after fork from process 28026
> >
> > Can you please help why this new process is being created and how to avoid this.
>
> On systems with a random device, libgcrypt uses an entropy gatherer
> which works by running dozens of system tools to gather stats about the
> system. The error message is likely from one of these tools. I don't
> know tryhe trace utility but if you can configure it to also show the
> exec call, you will see the culprit.
>
> An easier way to debug this is by setting the envvar:
>
> GNUPG_RNDUNIX_DBG=filename
>
> The actual code is cipher/rndunix.c .
>
> A failure of one of the tools is not a real problem. If track it down
> we might be able to exclude that tool for a certain version of HPUX.
>
>
> Shalom-Salam,
>
>
> Werner
>
>
>
> --
> Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
>
>



--
With regards,
Md. Haidar Habib
Senior Software Engineer
haidar.habib@aricent.com
Aricent
Gurgaon
Cell- 09350042332

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Mon, 18 Feb 2008 11:51, h.habib@gmail.com said:

> I have exported the variable and run the application as you suggested
> and got the following outful in file.
> But I don't know what to infer from this.

It does not look bad. If you want to get to the failing tool you need
to use your trace utility or chnage the code of rndlinux.c.

I don't known that the error message you posted is all about. Is it
even an error message worth to care about?

What is the actual problem you try to solve?


Shalom-Salam,

Werner


--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Hi Werner,

The problem what I am facing is that when I am running my application
with TLS enabled another process is created with the same executable
name as my application.
I am concerned of this new process as I have not forked any child
process in my application.
After debugging the problem I found out that after I called
gnutls_global_init() function at the time of initialization of TLS a
new process is forked printing following trace in console.

[New process 28026]
warning: reading `r3' register: No data
Detaching after fork from process 28026

As gnutls_global_init() function internally calls many gcrypt
functions which may fork a new process, I raised this issue.

One more think the same code is running fine in LINUX OS without
creating any new process.

Hope this clarifies the problem.

Haidar

On Feb 18, 2008 4:57 PM, Werner Koch <wk@gnupg.org> wrote:
> On Mon, 18 Feb 2008 11:51, h.habib@gmail.com said:
>
> > I have exported the variable and run the application as you suggested
> > and got the following outful in file.
> > But I don't know what to infer from this.
>
> It does not look bad. If you want to get to the failing tool you need
> to use your trace utility or chnage the code of rndlinux.c.
>
> I don't known that the error message you posted is all about. Is it
> even an error message worth to care about?
>
> What is the actual problem you try to solve?
>
>
>
> Shalom-Salam,
>
> Werner
>
>
> --
> Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
>
>



--
With regards,
Md. Haidar Habib
Senior Software Engineer
haidar.habib@aricent.com
Aricent
Gurgaon
Cell- 09350042332

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Mon, 18 Feb 2008 13:58, h.habib@gmail.com said:
> gnutls_global_init() function at the time of initialization of TLS a
> new process is forked printing following trace in console.
>
> [New process 28026]
> warning: reading `r3' register: No data
> Detaching after fork from process 28026

Frankly, I still don't understand the origin of this message. My
interpretation is that some process reads a register named r3 and
returns no data. Whatever this means. The entire output looks like a
system call trace utility - I don't know HPUX enough to tell.

> One more think the same code is running fine in LINUX OS without
> creating any new process.

Right. Thai is because it uses /dev/random. As stated when configuring
libgcrypt, you are better off running the EGD:

The performance of the Unix random gatherer module (rndunix) is not
very good and it does not keep the entropy pool over multiple
invocations of Libgcrypt base applications. The suggested way to
overcome this problem is to use the

Entropy Gathering Daemon (EGD)

which provides a entropy source for the whole system. It is written
in Perl and available at the GnuPG FTP servers. To enable EGD you
should rerun configure with the option "--enable-static-rnd=egd".
For more information consult the GnuPG webpages:

http://www.gnupg.org/download.html#egd



Salam-Shalom,

Werner


--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Hi Wernaer,

Thanks for your response.
Actually in HPUX machine there is no /dev/random device and I think
thats why libgcrypt is forking a new process.
As per your suggestion I tried to install EGD but couldn't do so in
HPUX because it's showing some errors.

So one way of avoiding this is to kill the new process which has been created.
Can you pls let us know will there be any problem if we kill the new
process which is created.

Regards,
Haidar

On Feb 18, 2008 9:26 PM, Werner Koch <wk@gnupg.org> wrote:
> On Mon, 18 Feb 2008 13:58, h.habib@gmail.com said:
> > gnutls_global_init() function at the time of initialization of TLS a
> > new process is forked printing following trace in console.
> >
> > [New process 28026]
> > warning: reading `r3' register: No data
> > Detaching after fork from process 28026
>
> Frankly, I still don't understand the origin of this message. My
> interpretation is that some process reads a register named r3 and
> returns no data. Whatever this means. The entire output looks like a
> system call trace utility - I don't know HPUX enough to tell.
>
> > One more think the same code is running fine in LINUX OS without
> > creating any new process.
>
> Right. Thai is because it uses /dev/random. As stated when configuring
> libgcrypt, you are better off running the EGD:
>
> The performance of the Unix random gatherer module (rndunix) is not
> very good and it does not keep the entropy pool over multiple
> invocations of Libgcrypt base applications. The suggested way to
> overcome this problem is to use the
>
> Entropy Gathering Daemon (EGD)
>
> which provides a entropy source for the whole system. It is written
> in Perl and available at the GnuPG FTP servers. To enable EGD you
> should rerun configure with the option "--enable-static-rnd=egd".
> For more information consult the GnuPG webpages:
>
> http://www.gnupg.org/download.html#egd
>
>
>
> Salam-Shalom,
>
>
> Werner
>
>
> --
> Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
>
>

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Tue, 19 Feb 2008 14:05, h.habib@gmail.com said:

> So one way of avoiding this is to kill the new process which has been created.
> Can you pls let us know will there be any problem if we kill the new
> process which is created.

The procersses are all supposed to be sort-lived - they should not stay
for a long time. If they this is a bug in that utility or we call it
with options which make it run too long.

To help you I need to know the name or the program used to exec that
process. It would also be helpful if you can tell us a bit more verbose
what your problem is and describe the environment. For example what
created the output you posted, etc.

If you don't want to send this to a public mailing list, you may
consider to hire a consultant (cf. http://www.gnupg.org/service.html).


Shalom-Salam,

Werner


--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Hi Werner,

> The procersses are all supposed to be sort-lived - they should not stay
> for a long time. If they this is a bug in that utility or we call it
> with options which make it run too long.

The process is not short-lived i.e. its remain as long as the original
process which created it is alive.



> To help you I need to know the name or the program used to exec that
> process. It would also be helpful if you can tell us a bit more verbose
> what your problem is and describe the environment. For example what
> created the output you posted, etc.

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

Here PID 24068 is our original process and 24068 is the child process
created by 24068.

Following is the code snipate where some gnutls and gcrypt function
has been called.
After debugging we have seen that whenever gnutls_global_init() is
called the new process is spawned.

We are using HP-UX JOSH B.11.11 U 9000/785 3695850352 unlimited-user
license machine.

If I kill process 24068 then also our process is running fine with
intact TLS functionality.

void init(string cafile, string certfile, string keyfile)
{
gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
int ret;
if( (ret=gnutls_global_init()) < 0)
{
cout<<"TLS initialization error. "<<gnutls_strerror(ret);
}
/*allocate*/
if ((ret = gnutls_certificate_allocate_credentials(&_cert_cred)) < 0)
{
cout<<"TLS memory error."<<gnutls_strerror(ret);
}

/*Now add all security files in TLS*/
/*CA file*/
if (cafile != "null")
{
if ((gnutls_certificate_set_x509_trust_file(_cert_cred,
cafile.c_str(), GNUTLS_X509_FMT_PEM)) < 0)
{
cout<<"Error reading :"<< cafile;
cout<<""<<gnutls_strerror(ret);
}
}
/*Certificate*/
if (certfile != "null")
{
if ((gnutls_certificate_set_x509_key_file(_cert_cred,
certfile.c_str(), keyfile.c_str(), GNUTLS_X509_FMT_PEM)) < 0)
{
cout<<"Error reading, certficate file,"<< certfile;
cout<<"with key file,"<< keyfile;
cout<<""<<gnutls_strerror(ret);
}
}
}


Regards,
Haidar


On Feb 20, 2008 12:05 AM, Werner Koch <wk@gnupg.org> wrote:
> On Tue, 19 Feb 2008 14:05, h.habib@gmail.com said:
>
> > So one way of avoiding this is to kill the new process which has been created.
> > Can you pls let us know will there be any problem if we kill the new
> > process which is created.
>
> The procersses are all supposed to be sort-lived - they should not stay
> for a long time. If they this is a bug in that utility or we call it
> with options which make it run too long.
>
> To help you I need to know the name or the program used to exec that
> process. It would also be helpful if you can tell us a bit more verbose
> what your problem is and describe the environment. For example what
> created the output you posted, etc.
>
> If you don't want to send this to a public mailing list, you may
> consider to hire a consultant (cf. http://www.gnupg.org/service.html).
>
>
> Shalom-Salam,
>
>
> Werner
>
>
> --
> Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
>
>



--
With regards,
Md. Haidar Habib
Senior Software Engineer
haidar.habib@aricent.com
Aricent
Gurgaon
Cell- 09350042332

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Wed, 20 Feb 2008 14:38, h.habib@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.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

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@gnupg.org> wrote:
> On Wed, 20 Feb 2008 14:38, h.habib@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.
>
>

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

"Haidar Habib" <h.habib@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@gnupg.org> wrote:
>> On Wed, 20 Feb 2008 14:38, h.habib@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.
>>
>>

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

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@josefsson.org> wrote:
> "Haidar Habib" <h.habib@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@gnupg.org> wrote:
> >> On Wed, 20 Feb 2008 14:38, h.habib@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.
> >>
> >>
>

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel