I wish it were a random occurrence, but I get that message every time.
And I know it's not an actual timeout either because the output says
the test takes 00:00:00 every time. Too bad I didn't pay more
attention in my Perl class many years ago...

Thanks for the idea, though.

(sorry about the subject, consider it done)

-- --Ben Benjamin P. August System Administrator - VPUE Stanford University

On Thu, Jan 24, 2008 at 04:24:37PM +0900, Everett, Vernon wrote:

Just got a strange request. One of my colleagues wants to be able to keep the raw data (as accessed from the "Client data available" link on most test pages. He is looking to keep an archive of at least 3 days.

I see we can set --store-clientlogs for this purpose, but it only keeps if there was a change. Is there a setting to keep the lot?

No, but you can easily put together a server-side module to grab the data from the "client" channel in Hobbit. If you just want to store it in one large file, then running bbcmd hobbitd_channel --channel=client cat >clientlogs.gz will do it. Pipe it through gzip to save space :-)

If you want to store it in separate files per host or do some other processing, see the hobbitd_rootlogin.pl script for an example of how to handle messages from the Hobbit channels.

How long are those files kept for? How is that specified?

The client logs stored by --store-clientlogs (which is ON by default) are kept until you delete them. There's no automatic cleanup.

Regards, Henrik

In the end, I re-tried implementing bb-roracle (also on deadcat) with
a full Oracle client install. After that, it was a matter of making
sure that the hobbit user could run the Oracle client. Turns out
Oracle client is pretty anal about its permissions.

I kept testing with sqlplus as root, and got mad because the scripts
themselves wouldn't run as hobbit. Then I realized that basically the
whole Oracle client install is owned and only executable by the oracle
user (and root). It got a little more complicated than that, but the
moral of the story is make sure that the Hobbit user can run everything.

-- --Ben Benjamin P. August System Administrator - VPUE Stanford University

Quoting "Gore, David W (David)" <david.gore at verizonbusiness.com>:

...

-----Original Message----- From: Benjamin P. August [mailto:baugust at stanford.edu] Sent: Wednesday, January 23, 2008 19:16 To: hobbit at hswn.dk Subject: [hobbit] Greetings and a question...

First off, I love Hobbit. A lot. I've been running it as a test in our department for almost 9 months now and I have convinced the boss to not renew the contract for our proprietary monitoring package (from a certain other Scandinavian country) in favor of using Hobbit. I just need to see if I can put donations on my corporate card. :)

But I do have one last question after all of that effusion. Is anyone out there running dbcheck.pl and had this error:

"Wed Jan 23 10:21:40 2008:ERROR on sid_name: Timeout connecting to DBI:Oracle:sid_name!"

I know it isn't a network problem because the hobbit user can connect using sqlplus just fine and the oratns check is OK. The required Perl modules installed OK... I think.

(no, sid_name is not our SID, name has been changed to protect the innocent)

Thanks!

Ben, did you ever get this to work. I am having the same problem. I can connect fine with sqlplus from a Linux host(Redhat running the Hobbit server) to a Solaris host running Oracle 10.x.x.x, but I cannot get the dbcheck.pl script to run. The script fails quickly with the same error message:

Thu May 15 18:54:34 2008:ERROR: Timeout connecting to DBI:Oracle:host=MYHOST;port=5521;sid=MYSID!

SID name and hostname changed in this email from what they really are. hostname, port, and sid in dbcheck.ini match what is used by sqlplus to connect correctly.

Any help would be appreciated.

~David

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk