Peter Kruse wrote:
Hello,
Anyway, I donnot test it yet, so not sure if it's really the fixing
for your issue. Could you please test it and post the result to the
mailing list? TIA!
Yes, the problem is gone, there are no more messages like that
in syslog.
OK. So it _was_ cat printing the
Peter Kruse wrote:
Hi,
Francis Montagnac wrote:
I think it would be better to only reset SIGPIPE to SIG_DFL (perhaps
also other signals) in the LRM just before exec'ing any external (ie:
not pertaining to heartbeat itself) commands like the RA's.
Is that hard to do? Or has somebody already
Francis Montagnac wrote:
I think that the father of this bash script (lrm?) is setting the
action of SIGPIPE to SIG_IGN, and then "cat" itself notice that and
resets it to a function printing that on stderr.
Re-thinking to that: cat should *not* trap SIGPIPE, but only checking
the return code o
Xun Sun wrote:
On 1/12/06, Peter Kruse <[EMAIL PROTECTED]> wrote:
Hello,
In one of my RAs there is a line like this:
( exportfs ; cat /proc/fs/nfs/exports ) | grep -q "^${export_dir}[ ]"
This line apparently produces these errors:
Jan 12 13:40:08 ha-test-1 lrmd: [16217]: info: RA output:
(
Xun Sun wrote:
On 1/12/06, Peter Kruse <[EMAIL PROTECTED]> wrote:
Hello,
In one of my RAs there is a line like this:
( exportfs ; cat /proc/fs/nfs/exports ) | grep -q "^${export_dir}[ ]"
This line apparently produces these errors:
Jan 12 13:40:08 ha-test-1 lrmd: [16217]: info: RA output:
(
Hello,
Anyway, I donnot test it yet, so not sure if it's really the fixing for
your issue. Could you please test it and post the result to the mailing
list? TIA!
Yes, the problem is gone, there are no more messages like that
in syslog.
Great!
Peter
I'll
Peter Kruse wrote:
Hi,
Francis Montagnac wrote:
I think it would be better to only reset SIGPIPE to SIG_DFL (perhaps
also other signals) in the LRM just before exec'ing any external (ie:
not pertaining to heartbeat itself) commands like the RA's.
Is that hard to do? Or has somebody
On 1/16/06, Peter Kruse <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Francis Montagnac wrote:
> >
> > I think it would be better to only reset SIGPIPE to SIG_DFL (perhaps
> > also other signals) in the LRM just before exec'ing any external (ie:
> > not pertaining to heartbeat itself) commands like the RA's
Hi,
Francis Montagnac wrote:
I think it would be better to only reset SIGPIPE to SIG_DFL (perhaps
also other signals) in the LRM just before exec'ing any external (ie:
not pertaining to heartbeat itself) commands like the RA's.
Is that hard to do? Or has somebody already done so?
Should I c
> It seems to me that we should be able to use pipes in RAs,
I agree.
> so I would advocate either having the LRM "un-ignore" SIGPIPE (if
> thats even possible) or not have heartbeat ignore it in the first
> place.
I think it would be better to only reset SIGPIPE to SIG_DFL (perhaps
also other
On 1/12/06, Francis Montagnac <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I think that the father of this bash script (lrm?) is setting the action
> of SIGPIPE to SIG_IGN, and then "cat" itself notice that and resets it
> to a function printing that on stderr.
>
> You can reproduce that reliably with th
> I think that the father of this bash script (lrm?) is setting the
> action of SIGPIPE to SIG_IGN, and then "cat" itself notice that and
> resets it to a function printing that on stderr.
Re-thinking to that: cat should *not* trap SIGPIPE, but only checking
the return code of every write (like i
Hi,
I think that the father of this bash script (lrm?) is setting the action
of SIGPIPE to SIG_IGN, and then "cat" itself notice that and resets it
to a function printing that on stderr.
You can reproduce that reliably with the following (that doesn't call a
shell to execute "cat"):
$ perl -e '
Hello again,
Peter Kruse wrote:
Xun Sun wrote:
On 1/12/06, Peter Kruse <[EMAIL PROTECTED]> wrote:
( exportfs ; cat /proc/fs/nfs/exports ) | grep -q "^${export_dir}[ ]"
I guess it's a shell specific behavior. If you are using Bash, I would
suggest removing the subshell construct.
b
Hello,
Xun Sun wrote:
Jan 12 13:40:08 ha-test-1 lrmd: [16217]: info: RA output:
(rg1:nfs1:monitor:stderr) cat:
Jan 12 13:40:08 ha-test-1 lrmd: [16217]: info: RA output:
(rg1:nfs1:monitor:stderr) write error
Jan 12 13:40:08 ha-test-1 lrmd: [16217]: info: RA output:
(rg1:nfs1:monitor:stderr) : Br
Hi,
Xun Sun wrote:
On 1/12/06, Peter Kruse <[EMAIL PROTECTED]> wrote:
Hello,
In one of my RAs there is a line like this:
( exportfs ; cat /proc/fs/nfs/exports ) | grep -q "^${export_dir}[ ]"
I guess it's a shell specific behavior. If you are using Bash, I would
suggest removing the subs
On 1/12/06, Peter Kruse <[EMAIL PROTECTED]> wrote:
> Hello,
>
> In one of my RAs there is a line like this:
>
> ( exportfs ; cat /proc/fs/nfs/exports ) | grep -q "^${export_dir}[ ]"
>
> This line apparently produces these errors:
>
> Jan 12 13:40:08 ha-test-1 lrmd: [16217]: info: RA output:
> (rg
On 1/12/06, Peter Kruse <[EMAIL PROTECTED]> wrote:
> Hello,
>
> In one of my RAs there is a line like this:
>
> ( exportfs ; cat /proc/fs/nfs/exports ) | grep -q "^${export_dir}[ ]"
>
> This line apparently produces these errors:
>
> Jan 12 13:40:08 ha-test-1 lrmd: [16217]: info: RA output:
> (rg
Hello,
In one of my RAs there is a line like this:
( exportfs ; cat /proc/fs/nfs/exports ) | grep -q "^${export_dir}[ ]"
This line apparently produces these errors:
Jan 12 13:40:08 ha-test-1 lrmd: [16217]: info: RA output:
(rg1:nfs1:monitor:stderr) cat:
Jan 12 13:40:08 ha-test-1 lrmd: [1621
19 matches
Mail list logo
