On Wed, Nov 23, 2011 at 02:09:57PM -0600, Dallas Clement wrote:
> trap CleanupExit KILL
For the record, you cannot trap SIGKILL.
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 Wednesday 23 November 2011, Andreas Schwab wrote:
> "Steven W. Orr" 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
"Steven W. Orr" 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 same interpret
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 le
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, r
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
>> + 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 (ye
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 report
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" != "" ]; the
> 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 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_MA
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
TMP=`gr
On Fri, Nov 18, 2011 at 2:35 PM, Greg Wooledge 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 the
Dallas Clement 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.
--
Andreas Schwab, sc
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 wa
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 2:07 PM, Greg Wooledge 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] execve("/bin/touch", ["to
On Fri, Nov 18, 2011 at 2:59 PM, Bob Proulx 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 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
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 usin
On Fri, Nov 18, 2011 at 6:16 AM, 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.
[pid 6747] execve("/bin/touch", ["touch", "/mnt/array1/.
2011/11/17 Dallas Clement
>
> 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 Hauge
23 matches
Mail list logo
