Hi all,
I'm seeing the following information in my client logs and it raises a couple of questions
2007-07-27 16:14:07 Task emcpp terminated, status 5 2007-07-27 16:14:07 Task temp terminated, status 5 2007-08-01 08:12:34 Task emcpp terminated, status 7 2007-08-01 08:12:34 Task temp terminated, status 7
First, is there any way to debug this? I want to know why these tests terminated and why is it logging. Secondly, what do the different status levels mean?
Any assistance would be appreciated Thanks -Grs- Gregory R Shea EMC Corporation
On Tue, Aug 14, 2007 at 08:20:49PM +0000, shea4th at comcast.net wrote:
I'm seeing the following information in my client logs and it raises a couple of questions
2007-07-27 16:14:07 Task emcpp terminated, status 5 2007-07-27 16:14:07 Task temp terminated, status 5 2007-08-01 08:12:34 Task emcpp terminated, status 7 2007-08-01 08:12:34 Task temp terminated, status 7
First, is there any way to debug this? I want to know why these tests terminated and why is it logging. Secondly, what do the different status levels mean?
The number is just the exit code from the script. Normally you'd have an "exit 0" at the end of the script when everything is OK.
These are custom client-side scripts you're running, so what the different status numbers mean I cannot tell.
Debugging - you can run the scripts by hand, and then get the exit code from the "$?" environment right after the script finishes.
Regards, Henrik
The number is just the exit code from the script. Normally you'd have an "exit 0" at the end of the script when everything is OK.
These are custom client-side scripts you're running, so what the different status numbers mean I cannot tell.
Debugging - you can run the scripts by hand, and then get the exit code from the "$?" environment right after the script finishes.
Regards, Henrik
Hi Henrik,
Nice to hear from you. I hope you're not still on vacation and answering this email. If you are, my apologies, this can wait, but I'm going to send the responses.
The exit status seems to be coming from Hobbit, line 528 in common/hobbitlaunch.c The emcpp is a custom script that checks EMC's PowerPath software on a given host. The temp is the temperature.sh (V4.0) script from deadcat. The emcpp script returns 0, temp script returns 1. The log data is from clientlaunch.log. My standard client package includes these tests, as most of the machines here do run PowerPath and DellOM. The interesting thing about temp is my BBOSTYPE variable has an extra carriage return in it. [hobbit at hershey ext]$ echo "$BBOSTYPE" linux
[hobbit at hershey ext]$ echo "\"$BBOSTYPE\"" "linux "
[hobbit at hershey ext]$ ../bin/bbcmd bash 2007-08-14 17:59:54 Using default environment file /apps/hobbit/client/etc/hobbitclient.cfg [hobbit at hershey ext]$ env SED=/bin/sed GREP=/bin/grep BBDISP=0.0.0.0 WCC=/usr/bin/wc BBDISPLAYS=128.221.22.29 HOSTNAME=hershey UPTIME=/usr/bin/uptime TAIL=/usr/bin/tail SHELL=/bin/bash TERM=xterm AWK=/bin/awk HISTSIZE=1000 WHO=/usr/bin/who BBCLIENTLOGS=/apps/hobbit/client/logs SSH_CLIENT=128.221.22.29 48509 22 DF=/bin/df -Pk BBOSTYPE=linux
HOBBITCLIENTHOME=/apps/hobbit/client SSH_TTY=/dev/pts/0 CUT=/bin/cut USER=hobbit LS_COLORS= LD_LIBRARY_PATH=:/usr/local/freetds/lib SORT=/bin/sort HEAD=/usr/bin/head SYBASE=/usr/local/freetds TOP=/usr/bin/top RM=/bin/rm DATE=/bin/date EXPR=/usr/bin/expr BBPORT=1984 PATH=/usr/kerberos/bin:/bin:/usr/bin:/sbin:/usr/sbin:/etc MAIL=/var/spool/mail/hobbit MV=/bin/mv EGREP=/bin/egrep PWD=/apps/hobbit/client/ext INPUTRC=/etc/inputrc PS=ps ax BB=/apps/hobbit/client/bin/bb LANG=en_US.UTF-8 MACHINE=hershey CP=/bin/cp LN=/bin/ln SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass MAXLINE=32768 HOME=/apps/hobbit SHLVL=2 TR=/usr/bin/tr ID=/usr/bin/id BBTMP=/apps/hobbit/client/tmp MACHINEDOTS=hershey LOGNAME=hobbit SSH_CONNECTION=128.221.22.29 48509 10.250.132.12 22 WC=/usr/bin/wc -l LS=/bin/ls LESSOPEN=|/usr/bin/lesspipe.sh %s FIND=/usr/bin/find BBHOME=/apps/hobbit/client DFCMD=/bin/df -Pk CONFIGCLASS=linux
CAT=/bin/cat TOUCH=/bin/touch G_BROKEN_FILENAMES=1 UNIQ=/usr/bin/uniq _=/bin/env [hobbit at hershey ext]$
Thanks for your assistance -Grs- Gregory R Shea EMC Corporation
In <9386A1ED977B3F448D2B2A38E7FCAB7806717CF4 at CORPUSMX30A.corp.emc.com> shea_greg at emc.com writes:
The exit status seems to be coming from Hobbit, line 528 in common/hobbitlaunch.c
No, it's from the script. The code you're referring to picks up the exit code from the child process that runs the script; or - if the process was terminated by a signal - then it picks up the signal number. hobbitlaunch uses the wait3() routine (line 512) to get the exit status code, and then the WIFEXITED/WEXITSTATUS macros (line 517/518) for a process that terminates normally and the WIFSIGNALED/WTERMSIG macros (line 527/528) for processes terminated by a signal. All of this comes from the child process exit code.
Linenumbers from Hobbit 4.2.0.
The emcpp script returns 0, temp script returns 1. The log data is from clientlaunch.log.
How did you check that? Remember to run the scripts as the Hobbit user, since access rights may be different for your account and the Hobbit account.
My standard client package includes these tests, as most of the machines here do run PowerPath and DellOM. The interesting thing about temp is my BBOSTYPE variable has an extra carriage return in it.
A bit unusual - BBOSTYPE normally comes from the "uname -s" output - but it's got nothing to do with the log messages you see.
Regards, Henrik
No, it's from the script. The code you're referring to picks up the exit code from the child process that runs the script; or - if the process was terminated by a signal - then it picks up the signal number. hobbitlaunch uses the wait3() routine (line 512) to get the exit status code, and then the WIFEXITED/WEXITSTATUS macros (line 517/518) for a process that terminates normally and the WIFSIGNALED/WTERMSIG macros (line 527/528) for processes terminated by a signal. All of this comes from the child process exit code.
Linenumbers from Hobbit 4.2.0.
The emcpp script returns 0, temp script returns 1. The log data is from clientlaunch.log.
How did you check that? Remember to run the scripts as the Hobbit user, since access rights may be different for your account and the Hobbit account.
$BBHOME/bin/bbcmd bash ./emcpp ; echo $?
My standard client package includes these tests, as most of the machines here do run PowerPath and DellOM. The interesting thing about temp is my BBOSTYPE variable has an extra carriage return in it.
A bit unusual - BBOSTYPE normally comes from the "uname -s" output - but it's got nothing to do with the log messages you see.
Response in other email
On Tue, Aug 14, 2007 at 06:11:37PM -0400, shea_greg at emc.com wrote:
The temp is the temperature.sh (V4.0) script from deadcat. The emcpp script returns 0, temp script returns 1. The interesting thing about temp is my BBOSTYPE variable has an extra carriage return in it. [hobbit at hershey ext]$ echo "$BBOSTYPE" linux
It seems version 4.1 of the temperature.sh script (cannot find 4.0) chokes on this, reporting
sh-3.2$ ./temperature.sh Unknown OS linux
sh-3.2$ echo $? 1
Henrik
The temp is the temperature.sh (V4.0) script from deadcat. The emcpp script returns 0, temp script returns 1. The interesting thing about temp is my BBOSTYPE variable has an extra carriage return in it. [hobbit at hershey ext]$ echo "$BBOSTYPE" linux
It seems version 4.1 of the temperature.sh script (cannot find 4.0) chokes on this, reporting
sh-3.2$ ./temperature.sh Unknown OS linux
sh-3.2$ echo $? 1
Exactly, temperature.sh checks the $BBOSTYPE variable for known OS types case "$BBOSTYPE" in solaris) get_temp_solaris ;; osf) get_temp_osf ;; linux|redhat) get_temp_omreport ;; *) echo "Unknown OS $BBOSTYPE" exit 1 esac
It should match on the linux|redhat) line but doesn't
-Grs-
On Wed, Aug 15, 2007 at 09:09:47AM -0400, shea_greg at emc.com wrote:
sh-3.2$ ./temperature.sh Unknown OS linux
sh-3.2$ echo $? 1
Exactly, temperature.sh checks the $BBOSTYPE variable for known OS types It should match on the linux|redhat) line but doesn't
No, because "linux<newline>" doesn't match "linux". You need to figure out where that extra newline comes from; the Hobbit client "runclient.sh" script picks it up from the "uname -s" output, and that should not (normally) include a newline. So either uname is broken on these boxes, or BBOSTYPE is being set somewhere else.
Regards, Henrik
sh-3.2$ ./temperature.sh Unknown OS linux
sh-3.2$ echo $? 1
Exactly, temperature.sh checks the $BBOSTYPE variable for known OS types It should match on the linux|redhat) line but doesn't
No, because "linux<newline>" doesn't match "linux". You need to figure out where that extra newline comes from; the Hobbit client "runclient.sh" script picks it up from the "uname -s" output, and that should not (normally) include a newline. So either uname is broken on these boxes, or BBOSTYPE is being set somewhere else.
In your example above, it shows the problem. The temperature.sh script gets the $BBOSTYPE from the environment, not set anywhere. Also from your example, the exit code from the script is 1. That's the same exit code I get when I run the script manually, but it exits because $BBOSTYPE don't match. Look near the bottom of the temperature.sh script. I have to assume that you're running Linux, so why does temperature.sh, exit 1 when you run it?
Whether or not I have convinced you of the above issue, how does the script terminate with a status of 5 or 7, when it returns 1?
Thanks -Grs-
Hi all,
regarding new 4.3.0 version I have a feature request.
Is it possible to introduce some "archiving" concept? Let me explain better.
On my Hobbit system I have 1-year and more history for some hosts. I would like to archive this history just like BigBrother can do using bbprune (as I remember right) or in a similar or better way.
What do you think about?
Regards.
Massimo Morsiani Information Technology Dept.
Gilbarco S.p.a. via de' Cattani, 220/G 50145 Firenze tel: +39-055-30941 fax: +39-055-318603 email: massimo.morsiani at gilbarco.com web: http://www.gilbarco.it
This message (including any attachments) contains confidential
and/or proprietary information intended only for the addressee.
Any unauthorized disclosure, copying, distribution or reliance on
the contents of this information is strictly prohibited and may
constitute a violation of law. If you are not the intended
recipient, please notify the sender immediately by responding to
this e-mail, and delete the message from your system. If you
have any questions about this e-mail please notify the sender
immediately.
participants (4)
-
henrik@hswn.dk
-
massimo.morsiani@gilbarco.com
-
shea4th@comcast.net
-
shea_greg@emc.com