Hi all,

I am running a Netbackup RH 7.1 client (Win2k Media/Master Server).
My diferrential backups are fine.  My full backup is consistently
disconnecting the socket(s) with a SIGPIPE error.  I am at a loss in
trying to find what is producing the SIGPIPE.

[5066] <16> bpbkar sighandler: ERR - bpbkar killed by SIGPIPE
[5066] <2> bpbkar sighandler: INF - ignoring additional SIGPIPE
signals

I see that gdb can be used to trap signals or redirect the action of
certain signals, is it possible to do this with a remote process?  Is
it possible to map the SIGPIPE such that it continues versus
terminates the process?

Any suggestions?

Thanks!

Tony

[ Post a follow-up to this message ]

Tony wrote:
quote:

> Hi all,
>
> I am running a Netbackup RH 7.1 client (Win2k Media/Master Server).
> My diferrential backups are fine.  My full backup is consistently
> disconnecting the socket(s) with a SIGPIPE error.  I am at a loss in
> trying to find what is producing the SIGPIPE.


It's probably the other way round.  If the server side closes a socket
the Linux based client will get a SIGPIPE when it tries to read from it
or write to it.  IOW, SIGPIPE is probably a symptom of a lost
connection rather than of what is causing it.

Use strace to trace the job and see what is happening to it.  The trace
should show what system call is generating the SIGPIPE.

-- ced

quote:

>
> [5066] <16> bpbkar sighandler: ERR - bpbkar killed by SIGPIPE
> [5066] <2> bpbkar sighandler: INF - ignoring additional SIGPIPE
> signals
>
> I see that gdb can be used to trap signals or redirect the action of
> certain signals, is it possible to do this with a remote process?  Is
> it possible to map the SIGPIPE such that it continues versus
> terminates the process?
>
> Any suggestions?
>
> Thanks!
>
> Tony




--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.

[ Post a follow-up to this message ]

Chuck Dillon <cdillon@nimblegen.com> writes:
quote:

>It's probably the other way round.  If the server side closes a socket
>the Linux based client will get a SIGPIPE when it tries to read from it
>or write to it.  IOW, SIGPIPE is probably a symptom of a lost
>connection rather than of what is causing it.


Only on write, not read.  (Traditionally, read return values are checked
because the number of bytes read is usually uncertain; writes are
often unchecked and are assumed not to fail; SIGPIPE terminates
such badly behaved programs)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

Casper H.S. Dik <Casper.Dik@Sun.COM> wrote in message news:<3f622f24$0$58713$e4fe514c@news.xs4all.
nl>...
quote:

> Chuck Dillon <cdillon@nimblegen.com> writes:
> 
>
> Only on write, not read.  (Traditionally, read return values are checked
> because the number of bytes read is usually uncertain; writes are
> often unchecked and are assumed not to fail; SIGPIPE terminates
> such badly behaved programs)
>
> Casper


Chuck and Casper,

Thank you for your response!

I am writing a script to strace the process and hopefully this will
show the origin of the failure and lead to a resolution.

Thanks again,

Tony

[ Post a follow-up to this message ]