Re: SOLVED: weird script behaviour

[Venkat Raju <raju@duh-uh.com>]

The return value of a process if it is terminated by a signal is
(128 + signal_number). Looks like ping is terminating on signal
13 SIGPIPE (Broken pipe: write to pipe with no readers).

Venkat

On Fri, May 23, 2003 at 08:57:03PM +0300, urgrue wrote
> well, it seems that i have to do it like this:
> ping -n -c 1 -w 3 10.155.x.y >/dev/null && continue
> 
> so far it seems that this way it will correctly pass 0 (and thus 
> "continue") if the ping goes, and something else if it doesnt (and thus not 
> "continue").
> what was happening was that, without the >/dev/null, the ping will send 0 
> roughly 14 times (why 14???) and then it starts passing 141!!
> 
> if anyone can tell me why this happens, and where that 141 comes from, id 
> be happy.
> there is no 141 in ping's output, and ping's return code ($?) is always 0, 
> 1, or 2 (was during my  tests, anyway). so i really dont get where that 141 
> comes from.
> 
> 
> 
> >A feature of running commands under 'at' is that 'at' includes the
> >environment that is current when you issue the 'at' command ... unlike 
> >cron,
> >which doesn't know squat about more than the basic environment.
> >
> >Rather than use 'bash,' why not try /bin/ksh?  bash may have some
> >requirements that are getting interfered with because it's cron running it.
> >I know you may be using 'bash' as your primary shell, but humor me.  Cron
> >likes bsh and ksh and most times csh.  Other times, it may have problems.
> >
> >Something that I've practiced since I started and has never failed me is to
> >try to code scripts and programs for the minimum number of features
> >necessary by using bsh where possible, ksh where necessary, and almost 
> >never
> >anything else (and to hard-code 'cron' entries as much as possible).  In
> >this way, conservative does the trick.  Sometimes you can't avoid other
> >programs, but most times you can.
> >
> >Ok.  Soapbox away ... sorry about the suds.
> >
> >
> >----------------------------------
> >Bruce T. Harvey (Special Projects)
> >----------------------------------------
> >bth@comcast.net  -- bruceh@routescape.com
> >443-465-1204 (personal) -- 410-403-2390 (office)
> >-------------------------------------------
> >Insight Distribution Systems / CoAxis, Inc.
> >Hunt Valley, Maryland  U.S.A.  21031-1422
> >-------------------------------------------
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: urgrue [mailto:urgrue@tumsan.fi]
> >Sent: Friday, May 23, 2003 8:49 AM
> >To: linux-admin@vger.kernel.org
> >Subject: weird script behaviour
> >
> >
> >i have script that runs ok from the prompt but doesnt run ok at all
> >from cron (yes we've all seen this before, but this time its weirder
> >than usually).
> >i even tried running it with env -i , but i cant reproduce the problem
> >at the shell - it only appears when started from cron.
> >the problem also does NOT appear when started with "at".
> >i snipped the script down to a bare test minimum and am still able to
> >reproduce the error, here it is:
> >
> >#!/bin/bash
> >
> >while true
> >do
> >sleep 1
> >echo "start" | logger
> >ping -n -c 1 -w 3 10.155.11.37 && continue
> >echo "we didnt continue..... | logger
> >done
> >
> >point is to spot if a ping doesnt go.
> >run from the prompt, it works fine - it pings every second and i never
> >get to the "we didnt continue" part.
> >run from cron, it may or may not run ok for a little while (a minute or
> >so), but then it starts to repeatedly reach the "we didnt continue"
> >part - and itll keep hitting that part over and over again until i
> >intervene.
> >with a little extra checking, i found out that the ping isn't returning
> >zero (as it does from the shell), but its returning 141! where does
> >this come from? why does it only start appearing after a minute or so?
> >
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>