Suggestions for next hobbit release 🔗 link

Hello Henrik!

I have some suggestions for the next hobbit release:
- reports from hosts which are not known by the server should appear in the error report of the hobbitd. That would make it easier to find misconfiguration especially with the hostname the client sends.
- Succesfully sent messages should be logged to ensure that the client works correctly. It would be enough to log the last sent message for having a static small size of the logfile
- Bugfix: The Linux client does not stop the vmstat-process by stopping hobbitclient. See the shell-output below:

[root@*** /]# ps -ef | grep hobbit
hobbit   28837     1  0 14:21 ?        00:00:00 /usr/local/hobbit/client/bin/hobbitlaunch --config=/usr/local/hobbit/client/etc/clientlaunch.cfg --log=/usr/local/hobbit/client/logs/clientlaunch.log --pidfile=/usr/local/hobbit/client/logs/clientlaunch.pid
hobbit   28917     1  0 14:36 ?        00:00:00 sh -c vmstat 300 2 1>/usr/local/hobbit/client/tmp/hobbit_vmstat.28907 2>&1; mv /usr/local/hobbit/client/tmp/hobbit_vmstat.28907 /usr/local/hobbit/client/tmp/hobbit_vmstat
hobbit   28919 28917  0 14:36 ?        00:00:00 vmstat 300 2
root     28938 27515  0 14:38 pts/2    00:00:00 grep hobbit
[root@*** /]# /etc/init.d/hobbitc stop
Hobbit client stopped
[root@*** /]# ps -ef | grep hobbit
hobbit   28917     1  0 14:36 ?        00:00:00 sh -c vmstat 300 2 1>/usr/local/hobbit/client/tmp/hobbit_vmstat.28907 2>&1; mv /usr/local/hobbit/client/tmp/hobbit_vmstat.28907 /usr/local/hobbit/client/tmp/hobbit_vmstat
hobbit   28919 28917  0 14:36 ?        00:00:00 vmstat 300 2
root     28960 27515  0 14:38 pts/2    00:00:00 grep hobbit


I hope you think these features could be useful and implement them into the next release.
Thanks and best regards
Christian

Hi Christian,

On Thu, Sep 15, 2005 at 02:56:46PM +0200, Christian Schlüter wrote:

You can already do that - in your hobbitserver.cfg, change BBGHOSTS:

BBGHOSTS="1"     # How to handle status messages from unknown hosts.
                 # 0=accept message, 1=discard message,
		 # 2=discard message and log the event

Set it to "2", and the "hobbitd" column will list the hostnames and IP's of all hosts whose messages were discarded.

- Succesfully sent messages should be logged to ensure that the client works correctly. It would be enough to log the last sent message for having a static small size of the logfile

Do you mean "logged on the client host", or "logged on the Hobbit
server" ? And the entire message, or just that it was sent ? Big difference ...

On clients, the latest message is in ~hobbit/client/tmp/msg.txt .
On the Hobbit server, I do not want to log incoming messages for
performance reasons.

- Bugfix: The Linux client does not stop the vmstat-process by stopping hobbitclient.

Right ... the vmstat is started as with "nohup" to let it run
independently of all the other client tasks (it's the only one that
takes a long time). So this is a bit harder to do than it seems - hobbitlaunch which is the only other job running doesn't know the
process-id of the vmstat process.


Henrik

Christian Schlüter wrote:

I can confirm this.

I also got script errors and weird client behavior from the 4.1.2 snapshots because of a missing hobbitclient-rhel3.sh script (which happens when you use "runclient.sh --os=rhel3"

Tom

Henrik,

Thanks for Hobbit!

Just tried to do a clean build of the latest snapshot and got this (I've just included the last part of the make output)

gcc -g -O2 -Wall -Wno-unused -D_REENTRANT -DLINUX -I. -I/usr/local/src/hobbit/snapshot/include -I/usr/include -I/usr/include -I/usr/include -c -o do_rrd.o do_rrd.c
In file included from do_rrd.c:224:
rrd/do_vmstat.c: In function `do_vmstat_rrd':
rrd/do_vmstat.c:275: error: `vmstat_linux22_layout' undeclared (first use in this function)
rrd/do_vmstat.c:275: error: (Each undeclared identifier is reported only once
rrd/do_vmstat.c:275: error: for each function it appears in.)
rrd/do_vmstat.c:279: error: `vmstat_rhel3_layout' undeclared (first use in this function)
make[1]: *** [do_rrd.o] Error 1
make[1]: Leaving directory `/usr/local/src/hobbit/snapshot/hobbitd'
make: *** [hobbitd-build] Error 2

Previous snapshots have been OK upto now. 

Just though I'd pass this on...

Cheers,

Rob

-----Original Message-----
From: Henrik Stoerner [mailto:user-ce4a2c883f75@xymon.invalid] 
Sent: 15 September 2005 14:38
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Suggestions for next hobbit release

Hi Christian,

On Thu, Sep 15, 2005 at 02:56:46PM +0200, Christian Schlüter wrote:

You can already do that - in your hobbitserver.cfg, change BBGHOSTS:

BBGHOSTS="1"     # How to handle status messages from unknown hosts.
                 # 0=accept message, 1=discard message,
		 # 2=discard message and log the event

Set it to "2", and the "hobbitd" column will list the hostnames and IP's of all hosts whose messages were discarded.

Do you mean "logged on the client host", or "logged on the Hobbit
server" ? And the entire message, or just that it was sent ? 
Big difference ...

On clients, the latest message is in ~hobbit/client/tmp/msg.txt .
On the Hobbit server, I do not want to log incoming messages for
performance reasons.

Right ... the vmstat is started as with "nohup" to let it run
independently of all the other client tasks (it's the only one that
takes a long time). So this is a bit harder to do than it seems - 
hobbitlaunch which is the only other job running doesn't know the
process-id of the vmstat process.


Henrik

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

On Thu, Sep 15, 2005 at 04:05:25PM +0100, Watson, Robert wrote:

I know. I'm working on making the vmstat handling automatically
figure out what format the vmstat data has, so you need not
bother with special handling of RHEL servers.


Henrik