Patch has been applied to the trunk.
--Renier
[EMAIL PROTECTED] wrote on 05/13/2008 06:50:58
AM:
> Hello Renier,
>
> After applying the patch provided by you, I tried the following
> scenarios on the i386 server with RHEL 5.1:
>
> [EMAIL PROTECTED] ~]# uname -a
> Linux aotpprl3 2.6.18-53.el5PAE #1 SMP Wed Oct 10 16:48:18 EDT 2007
> i686 i686 i386 GNU/Linux
> Scenarios:
> 1. Running openhpid in background directly in a shell (i.e. openhpid
> -c /etc/openhpi/openhpi.conf) and run hpitop client(at least 2-3 times)
> 2. Running openhpid using service utility (service openhpid start)
> and run hpitop client(at least 2-3 times)
> 3. Incorporate openhpid into the standard run levels of OS, start
> the openhpid using service utility,
> reboot the server and check that openhpid is running after restart.
> Run hpitop client(atlease 2-3 times)
>
> Scenario 1: Running openhpid in background directly in a shell:
>
> 1. export OPENHPI_DEBUG=YES and export OPENHPI_DEBUG_TRACE=YES(This
> step is not mandatory, but just trying out to check for some errors)
> 2. Start openhpid -c /etc/openhpi/openhpi.conf (this is same conf
> used for previous execution, contain libipmi to non existent machine)
> 3. ran hpitop multiple times, the wrong version error is not reported.
>
> Scenario 2: Running openhpid using service utility
>
> 1. service openhpid start
> 2. ran hpitop multiple times, the wrong version error is not reported.
>
> Scenario 3: Incorporate openhpid startup into rc.local, start the
> openhpid using service utility,
> reboot the server and check that openhpid is running after restart.
> Run hpitop client(at least 2-3 times):
>
> 1. openhpid is started when the OS boots up
> 2. ran hpitop multiple times, the wrong version error is not reported.
>
> With the above testing, I feel that the patch has addressed the
> issue and is the fix for the bug id 1939812.
>
> Thanks for the patch.
>
> Regards,
> MS
>
>
>
> From: [EMAIL PROTECTED] [mailto:openhpi-
> [EMAIL PROTECTED] On Behalf Of Renier Morales
> Sent: Tuesday, May 13, 2008 10:30 AM
> To: [email protected]
> Subject: Re: [Openhpi-devel] Regarding bug id 1939812 (openhpid
> doesnt work correctly for non-existent machine)
>
> [EMAIL PROTECTED] wrote on 05/12/2008 10:38:51
AM:
>
> > Hello Zhang Huan,
> > I was finally able to reproduce the bug in my i386 server installed
> > with RHEL5.1.
> >
> > As identified by you, this bug is reproducible only when the
> > openhpid process is run in the background
> > (done by invoking the openhpid using service utility, i.e. "service
> > openhpid start" or
> > by running the openhpid in background directly i.e. "openhpid -c
> > /etc/openhpi/openhpi.conf")
> >
> (snip)
> >
> > When the openhpid is started in background, ipmi connection error is
> > reported and the openhpid continuously tries to discover with no
success.
> >
> > When the hpitop client is started, there is stream socket connection
> > established between openhpid process and hpitop client program.
> > Since openhpid is running in the background, File handlers like
> > stderr, stdout and stdin are not attached to any TTY.
>
> A daemon inherits file descriptors from its parent and has access to
> them even when running in the background.
>
> > But for reporting the ipmi connection error, the IPMI plugin tries
> > to write into stderr using fprintf (plugins/ipmi/ipmi.c, line no
> > 604), this error message gets into data stream being read by client:
> >
> > Extract of ipmi.c:
> >
> > 602 while (ipmi_handler->fully_up == 0) {
> > 603 if (!ipmi_handler->connected) {
> > 604 fprintf(stderr, "IPMI connection is
down\n");
> > 605 return SA_ERR_HPI_NO_RESPONSE;
> > 606 }
> >
> >
> > (gdb) print data
> > $12 = 0xbfc14d2b "IPMI connection is down\n\001\021"
> > (gdb) print *data
> > $13 = 73 'I'
> >
> > Provided above is the corrupted message content received at hpitop
> > client's side (Captured in gdb).
> > Due to this problem the ReadMsg reports wrong version error.
> >
> (snip)
>
> This analysis helped me understand the problem a great deal. Thanks MS.
>
> I found that the daemon was closing the stdout and stderr
> descriptors on startup. The problem was harder to find since the
> return code of fprintf is not examined by the code. I believe
> fprintf must be returning an error in that case, since its trying to
> write to an invalid descriptor.
>
> >
> > Testing and findings on openhpi.2.11.2:
> > =============================
> > The scenario here is much different, the definition of the "dbg"
> > statements are written to stderr and hence most of the dbg statement
> > gets mixed with the data being read by hpitop client program.
> >
> > In 2.10.2, the dbg statements were written to syslog rather than
stderr.
> >
> > Any suggestions on finding the solution for openhpi trunk.
>
> I have attached a patch that keeps stdout and stderr open. I was
> able to reproduce the problem at home and the patch fixes the "wrong
> version" error.
> One thing to try though is to set the openhpid service to start on
> machine startup with the same openhpi.conf, and test with the hpi
> clients after a fresh reboot. If the "wrong version" problem appears
> again, even with the patch, then we need to figure out how to create
> stdout/stderr when they don't exist for the daemon initially.
>
> Please, try the patch out and let me know.
>
> --Renier
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
