I have a script which uses ping to check if a system is on the network. It works fine when run from a terminal or when detached from a terminal but if it is started in the background ping has an exit code of 141 and a look through a strace output suggests there is a broken pipe.
I need to have the script running in the background so it would be useful to find a solution. I wondered if it was because background tasks don’t always run /etc/profile so I’ve added that to the script but it didn’t change the situation.
Apart from the fact that you forgot to mention what level of openSUSE you use (addrssed alllready above), you should at least have shown us the statement you use (or even the whole script when it is not to large). Same for the error message and at least it’s surrounding output (when not all of it). Now we have nothing but your story.
openSUSE 12.1 (i586)
VERSION = 12.1
CODENAME = Asparagus
This is the section of the script where the ping is used:
/bin/ping -q -c1 -W5 ${remhost}
if $? -eq 0 ]
then
if ${remstatus} -ne 2 ]
then
logit 1 Comms: Remote host now responding over VPN
fi
remstatus=2
remroute=${remhost}
else
# default to the router even if we fail the ping
remroute=${remrouter}
/bin/ping -q -c1 -W5 ${remrouter}
resp=$?
if ${resp} -eq 0 ]
then
if ${remstatus} -ne 1 ]
then
logit 1 Comms: Remote host not responding over VPN - using router
fi
remstatus=1
else
remstatus=0
inc_timeout remote ping fail - response = ${resp}
fi
fi
remhost is the machine name when I am running over a VPN connection and remrouter is the url of the router on the remote end.
Because this is running in the background when it goes wrong I can’t actually supply details of the flow, merely that when inc_timeout logs the error $resp is 141. If I run it as a detached process from a terminal the error does not occur.
I hesitate to put strace output into here because of the size.
Apologies for not supplying all this information on the original posting.
Am 13.07.2012 15:16, schrieb davidlwilcox:
> /bin/ping -q -c1 -W5 ${remhost}
To narrow that down:
What happens when you redirect the output of that command to /dev/null?
Do you still get the broken pipe problem?
Assuming the ping returns the usual <some_value>+<signal_number> code
when terminated by a signal (where some_value=128 for bash and
signal_number=13 is SIGPIPE) that would correspond to your finding with
strace.
–
PC: oS 12.1 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.1 x86_64 | i3@2.30GHz | 8GB | KDE 4.8.4 | HD 3000
eCAFE 800: oS 12.1 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
Thank you for your assistance, redirecting the output to /dev/null has cured the problem. Thinking about it I suppose it is logical that an interactive command really needs somewhere to send its output.
Also, apologies for not putting the script inside the # tags but I took the request literally when I was told to put all computer OUTPUT between the tags and it hadn’t occured to me that this applied to scripts as well. I will try to do better next time.
Am 13.07.2012 17:46, schrieb hcvv:
> In any case next time better and thanks to Martin for trying to
> interprete that mess
It was almost a blind shot, not even an educated guess
–
PC: oS 12.1 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.1 x86_64 | i3@2.30GHz | 8GB | KDE 4.8.4 | HD 3000
eCAFE 800: oS 12.1 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
It could however be quite possible that when you copy/paste from your TextPad between CODE tags, at least the most important features of the CODE tags would be used, like:
. clear boundary between computer facts and story telling;
. fixed font, which will prevent a lot of misreading allready;
. hopefully preservation of white space, which will bring us the joy of your perfect programming style;
. prevent conversion of certain character combinations into smileys;
. prevent from strings that could be interpreted as URLs to be converted into links;
What we may loose is the command (cat in this case) and the prompt. This will tell the carefull reader if you were root or not and where your working directory was doing the command. Both are not very important in this case, but they often reveal how an OP messed up things.