Steven W. Orr ste...@syslang.net writes:
I think we're beating this one to death, but I have point out that
telling perl to run a print command whose output is redirected by bash
is not the same as telling bash to run a builtin echo command that is
redirected as an integral operation of the
On Wednesday 23 November 2011, Andreas Schwab wrote:
Steven W. Orr ste...@syslang.net writes:
I think we're beating this one to death, but I have point out that
telling perl to run a print command whose output is redirected by bash
is not the same as telling bash to run a builtin echo
Hi All,
Just wanted to let you know that I have found a solution to my
problem, though I can't entirely explain it yet. As mentioned
earlier, this script was designed to run as a daemon, i.e. run in the
background. This is what I was doing to daemonize the script:
Daemon()
{
while :
On Wed, Nov 23, 2011 at 02:09:57PM -0600, Dallas Clement wrote:
trap CleanupExit KILL
For the record, you cannot trap SIGKILL.
It turns out that my 'touch' command is actually getting executed, but
not when I expect it. Here is a recap of my script function which is
occasionally misbehaving:
# $1 mntpoint
fsaccesstest()
{
local RETRY_MAX=3
local RETRY_INTERVAL=3
local CHK_RESULT=1
On Tue, Nov 22, 2011 at 11:31:22AM -0600, Dallas Clement wrote:
It turns out that my 'touch' command is actually getting executed, but
not when I expect it. Here is a recap of my script function which is
occasionally misbehaving:
# $1 mntpoint
fsaccesstest()
{
local RETRY_MAX=3
That makes no sense. Fix your quoting (it's atrocious) and then run
the function with set -x. Don't throw strace at it, at this point.
It's really not the right tool at this level of debugging.
Okay, I simplified the script slightly, fixed the quoting and re-ran
with set -x. Here is the
On Tue, Nov 22, 2011 at 02:55:28PM -0600, Dallas Clement wrote:
fsaccesstest()
{
set -x
local RETRY_MAX=3
local RETRY_INTERVAL=3
local CHK_RESULT=1
local RETVAL=0
TMP=`grep $1 /proc/mounts|awk '{print $1}'`
if [ $TMP != ]; then
Dallas Clement wrote:
Okay, I simplified the script slightly, fixed the quoting and re-ran
with set -x. Here is the script and the output for the failure
scenario.
Much more useful! Thanks.
+ touch /mnt/array1/.accesstest
+ CHK_RESULT=1
It looks to me that touch is failing and reporting
+ touch /mnt/array1/.accesstest
+ CHK_RESULT=1
It looks to me that touch is failing and reporting the failure and
that bash is handling it correctly.
+ touch /mnt/array1/.accesstest
+ CHK_RESULT=0
And then on a subsequent pass touch is reporting success.
This doesn't (yet) look like a
Dallas Clement wrote:
This doesn't (yet) look like a problem with bash.
Admittedly bash seems to do the right thing if you go by the set -x
execution trace. If you go by that, it would indeed seem that the
call to touch is failing.
I have a higher level of trust in -x output since I
Bob, Yes I agree with everything you've said. I am grasping at
straws, which I really don't like. It's very unlikely that the
problems are with any of these things I've mentioned bash, Linux
kernel, compiler, libc etc. This script is fairly large and it does
lots of checking of block devices,
On 11/22/2011 6:49 PM, Bob Proulx wrote:
Dallas Clement wrote:
This doesn't (yet) look like a problem with bash.
Admittedly bash seems to do the right thing if you go by the set -x
execution trace. If you go by that, it would indeed seem that the
call to touch is failing.
I have a higher
2011/11/17 Dallas Clement dallas.a.clem...@gmail.com
Would appreciate any insight you could offer. Here is my script and
the strace output for when touch returns 1.
Add ''set -x'' at the start of the function and examine the output to see
if it actually runs touch from PATH.
--
Geir
On Fri, Nov 18, 2011 at 6:16 AM, Geir Hauge geir.ha...@gmail.com wrote:
Add ''set -x'' at the start of the function and examine the output to see if
it actually runs touch from PATH.
The strace output is showing that the correct 'touch' is being executed.
[pid 6747] execve(/bin/touch, [touch,
Dallas Clement wrote:
Geir Hauge wrote:
Add ''set -x'' at the start of the function and examine the output
to see if it actually runs touch from PATH.
The strace output is showing that the correct 'touch' is being executed.
It would be a lot easier to use the 'sh -x' trace than using
On Fri, Nov 18, 2011 at 01:49:38PM -0600, Dallas Clement wrote:
[pid 6747] execve(/bin/touch, [touch, /mnt/array1/.accesstest],
[/* 14 vars */]) = 0
Process 6748 attached
Process 13686 suspended
[pid 6748] execve(/usr/bin/logger, [logger, -s, -t,
diskmon, -p, local0.info, *** fsaccesstest
On Fri, Nov 18, 2011 at 2:59 PM, Bob Proulx b...@proulx.com wrote:
Dallas Clement wrote:
Geir Hauge wrote:
Add ''set -x'' at the start of the function and examine the output
to see if it actually runs touch from PATH.
The strace output is showing that the correct 'touch' is being executed.
On Fri, Nov 18, 2011 at 2:07 PM, Greg Wooledge wool...@eeg.ccf.org wrote:
Notice that the child process pid=6747 exits with status 0
Where does it say that? How are you even invoking strace here? I don't
know how to read this output, nor do I know how to reproduce it.
[pid 6747]
DJ Mills wrote:
Bob Proulx wrote:
sh -x ./scripttodebug
I'm guessing you mean bash -x, not sh -x. Two different shells.
It is a bash list so I probably should have said bash just to be
politically correct. But the script doesn't use any bash specific
constructs so sh should be fine.
On Fri, Nov 18, 2011 at 02:23:54PM -0600, Dallas Clement wrote:
[pid 6747] execve(/bin/touch, [touch, /mnt/array1/.accesstest],
[/* 14 vars */]) = 0
The = 0 at the end is the exit status.
That is the return value of the execve() call. All it means is that
the /bin/touch program was
Dallas Clement dallas.a.clem...@gmail.com writes:
[pid 6747] execve(/bin/touch, [touch, /mnt/array1/.accesstest],
[/* 14 vars */]) = 0
The = 0 at the end is the exit status.
No, it isn't. It only says that execve was successful. The exit status
is set by the exit syscall.
Andreas.
--
On Fri, Nov 18, 2011 at 2:35 PM, Greg Wooledge wool...@eeg.ccf.org wrote:
On Fri, Nov 18, 2011 at 02:23:54PM -0600, Dallas Clement wrote:
[pid 6747] execve(/bin/touch, [touch, /mnt/array1/.accesstest],
[/* 14 vars */]) = 0
The = 0 at the end is the exit status.
That is the return value of
Hello,
I've got a script that is periodically performing a disk / raid array
integrity check by touching a file. The touch is failing
occasionally, with an exit status of 1. If I do 'strace touch'
instead of just 'touch' the strace indicates an exit status of 0. So
I'm not sure why this is
24 matches
Mail list logo
