<br><br><div class="gmail_quote">On Thu, Aug 4, 2011 at 9:10 PM, David Nutter <span dir="ltr"><<a href="mailto:davidn@bioss.ac.uk">davidn@bioss.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Aug 04, 2011 at 12:41:13PM +0100, David Nutter wrote:<br>
> On Tue, Aug 02, 2011 at 07:34:46PM +0100, David Nutter wrote:<br>
> > On Tue, Jul 26, 2011 at 11:27:19AM +0530, trm asn wrote:<br>
> ><br>
> > *snip*<br>
> ><br>
> > > 'ProbeRecord', 'get_hostAddress') ; that error I have resolved by editing<br>
> > > "NPRecords.pm" & changed the parameter "hostAddress" to "HOSTADDRESS" .<br>
> > ><br>
> > > now my "scout config push" are getting success, but unfortunately still the<br>
> > > monitoring status is "PENDING, Awaiting Update" .<br>
> > ><br>
> > ><br>
> > > -bash-3.2$ rhn-runprobe --probe=261 --log=all=4<br>
> > > Can't locate object method "hostname" via package<br>
> > > "NOCpulse::Probe::Config::ProbeRecord" at<br>
> > > blib/lib/Class/MethodMaker/Engine.pm (autosplit into<br>
> > > blib/lib/auto/Class/MethodMaker/Engine/<a href="http://new.al" target="_blank">new.al</a>) line 941.<br>
> > ><br>
> > > Any idea...<br>
> ><br>
> > Hi,<br>
> ><br>
><br>
> *snip*<br>
><br>
> After a bit more digging I've narrowed down the problem area.<br>
><br>
> The method NOCpulse::Probe::Shell::Unix::connect seems to be failing<br>
> when running under the scheduler but not when running under<br>
> rhn-runprobe.<br>
<br>
</div>*snip*<br>
<div class="im"><br>
> What seems to be happening on the scheduler is the command's STDOUT is<br>
> getting written to the logfile and not read by Unix::read_result. In<br>
> the first trace you can see this in the last two log lines:<br>
><br>
> 2011-08-04 12:31:44 Linux#2.6.18-238.12.1.el5xen#2834<br>
> 2011-08-04 12:31:44 NOCPULSE-1312457503-STATUS 0<br>
<br>
</div>Got it. At long last. We're being bitten by this perl bug:<br>
<br>
<a href="https://rt.perl.org/rt3/Public/Bug/Display.html?id=66224" target="_blank">https://rt.perl.org/rt3/Public/Bug/Display.html?id=66224</a><br>
<br>
The test script there does indeed fail on my CentOS 5.6 system.<br>
<br>
Reason is that Process.pm redirects STDOUT and STDERR before spawning<br>
the probe runner. Then, the STDOUT of any subsequent processes<br>
(e.g. those started by open3 in Unix.pm) ends up going to STDOUT, not<br>
the IO::Handle created for it to write to.<br>
<br>
I believe rhn-runprobe doesn't exhibit the problem because it doesn't<br>
use Process.pm just calls the ProbeRunner directly.<br>
<br>
Anyway, applying the patch below from the perl bug report does indeed fix<br>
the problem on my spacewalk. All probes now update in the web UI and<br>
appear to be recording data.<br>
<br>
--- Open3.pm.~1~ 2005-03-19 18:43:52.000000000 +0100<br>
+++ Open3.pm 2010-04-29 10:30:54.000000000 +0200<br>
@@ -200,6 +200,9 @@<br>
# A tie in the parent should not be allowed to cause problems.<br>
untie *STDIN;<br>
untie *STDOUT;<br>
+ open(STDOUT, ">&=1");<br>
+ open(STDERR, ">&=2");<br>
+<br>
# If she wants to dup the kid's stderr onto her stdout I need<br>
to<br>
# save a copy of her stdout before I put something else there.<br>
if ($dad_rdr ne $dad_err && $dup_err<br>
<br>
Question is, do I file a bug against RHEL5 or look at rewriting the<br>
logic in UnixCommand.pm to work around the issue? I hardly think that<br>
patching core perl modules is a sensible thing to do on a production server!<br>
<div><div></div><div class="h5"><br>
Regards,<br>
<br>
--<br>
David Nutter Tel: +44 (0)131 650 4888<br>
BioSS, JCMB, King's Buildings, Mayfield Rd, EH9 3JZ. Scotland, UK<br><br></div></div></blockquote><div>Hi ,</div><div><br></div><div>Here I am getting another error after changing the above mentioned parameters,</div>
<div><br></div><div>Status:
UNKNOWN, The RHN Monitoring Daemon
(RHNMD) is not responding: Auto configuration failed
11851:error:0200100D:system library:fopen:Permission
denied:bss_file.c:122:fopen('/etc/pki/tls/openssl.cnf','rb')
11851:error:2006D002:BIO routines:BIO_new_file:system
lib:bss_file.c:127: 11851:error:0E078002:configuration file
routines:DEF_LOAD:system lib:conf_def.c:199:. Please make sure the
daemon is running and the host is accessible from the monitoring scout.
Command was: /usr/bin/ssh -l nocpulse -p 4545 -i
/var/lib/nocpulse/.ssh/nocpulse-identity -o StrictHostKeyChecking=no -o
BatchMode=yes 192.169.1.20 /bin/sh -s </div><div><br></div><div><br></div><div>But if I do from spacewalk server ....</div><div><br></div><div>su - nocpulse</div><div>-bash-3.2$ ssh -i /var/lib/nocpulse/.ssh/nocpulse-identity <a href="mailto:nocpulse@192.168.1.20">nocpulse@192.168.1.20</a></div>
<div><br></div><div><div>Last login: Fri Aug 5 11:16:33 2011 from 192.168.1.100</div><div>-bash-3.2$</div></div></div><div><br></div><div><div>-bash-3.2$ /usr/bin/ssh -l nocpulse -p 4545 -i /var/lib/nocpulse/.ssh/nocpulse-identity -o StrictHostKeyChecking=no -o BatchMode=yes 192.168.1.20 /bin/sh -s</div>
<div>free -m</div><div> total used free shared buffers cached</div><div>Mem: 1000 779 221 0 128 467</div><div>-/+ buffers/cache: 182 817</div>
<div>Swap: 4094 185 3909</div><div>Killed by signal 2.</div></div><div><br></div><div>it's connecting and giving the output without an issue..</div><div><br></div><div>Any idea..........</div><div>
<br></div><div><br></div><div><br></div><div><br></div>