Veritas-bu

Re: [Veritas-bu] Status 249 on Linux Server

2007-09-12 10:31:16
Subject: Re: [Veritas-bu] Status 249 on Linux Server
From: "Brooks, Jason" <brooksje AT longwood DOT edu>
To: Andrew Sydelko <andrew AT sydelko DOT org>, "veritas-bu AT mailman.eng.auburn DOT edu" <veritas-bu AT mailman.eng.auburn DOT edu>
Date: Wed, 12 Sep 2007 10:12:44 -0400
Thanks.  We're moving to 6.5 next week, if other fires stay down.
Hopefully, that will fix it. 

> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu 
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf 
> Of Andrew Sydelko
> Sent: Wednesday, September 12, 2007 9:59 AM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Cc: Brooks, Jason
> Subject: Re: [Veritas-bu] Status 249 on Linux Server
> 
> On Wed, 12 Sep 2007 09:50:01 -0400
> "Brooks, Jason" <brooksje AT longwood DOT edu> wrote:
> 
> > I've been watching 249s pop up periodically on a couple of 
> Linux servers.
> > For the most part, they're Oracle DB Servers, but we don't use the 
> > Oracle agent, just a dump to file and backup the file.
> >
> > We're running NBU master/media on Win2K3, 6.0MP4.
> >
> > Client is Linux at 6.0MP4.
> >
> > What I've seen in the client logs are the following:
> > 23:57:07.183 [12441] <4> bpbkar main: INF - Client 
> completed sending 
> > data for backup
> >
> > 23:57:07.317 [12441] <2> bpbkar main: INF - Total Size:122408951
> > 23:57:07.317 [12441] <2> bpbkar delete_old_files_recur: INF 
> - checking 
> > files in directory /usr/openv/netbackup/hardlink_info for prefix = 
> > hardlinks_ and older than 30 days
> > 23:57:07.317 [12441] <2> bpbkar delete_old_files_recur: INF 
> - checking 
> > files in directory /usr/openv/netbackup/hardlink_info/root 
> for prefix 
> > = hardlinks_ and older than 30 days
> > 23:57:07.317 [12441] <2> bpbkar delete_old_files_recur: INF 
> - checking 
> > files in directory /usr/openv/netbackup/logs/user_ops for 
> prefix = jbp 
> > and older than 3 days
> > 23:57:07.317 [12441] <2> bpbkar delete_old_files_recur: INF 
> - checking 
> > files in directory /usr/openv/netbackup/logs/user_ops/nbjlogs for 
> > prefix = jbp and older than 3 days
> > 23:57:07.317 [12441] <2> bpbkar delete_old_files_recur: INF 
> - checking 
> > files in directory /usr/openv/netbackup/logs/user_ops/root 
> for prefix 
> > = jbp and older than 3 days
> > 23:57:07.317 [12441] <2> bpbkar delete_old_files_recur: INF 
> - checking 
> > files in directory /usr/openv/netbackup/logs/user_ops/root/logs for 
> > prefix = jbp and older than 3 days
> > 23:57:07.317 [12441] <2> bpbkar delete_old_files_recur: INF 
> - checking 
> > files in directory /usr/openv/netbackup/logs/user_ops/root/jobs for 
> > prefix = jbp and older than 3 days
> > 23:57:07.317 [12441] <4> bpbkar Exit: INF - bpbkar exit normal
> > 23:57:07.318 [12441] <32> handle_core_signals: FTL - terminated by 
> > signal 11
> > 23:57:07.318 [12441] <16> bpbkar Exit: ERR - bpbkar FATAL 
> exit status = 130:
> > system error occurred
> >
> > Has anyone seen the 130 for bpbkar before?  The only technote I've 
> > found is this one, pertaining to 5.1:
> > http://seer.entsupport.symantec.com/docs/278835.htm
> >
> > I've seen something else that indicates that there is a 
> limitation to 
> > NBU Unix clients that the path must be less than 1023 
> characters.  The 
> > paths I'm seeing are quite short, relatively speaking, less 
> than 100 characters.
> >
> > Not seeing anything concrete with NBU 6.0 either.
> 
> It's a known issue that was resolved in 6.0 MP5. The item in 
> the MP5 README is:
> 
> Etrack Incident = ET983962
> 
> Description:
>     An earlier change was made to keep track of open file
>     descriptors.  Descriptors are pushed onto a stack as files
>     are opened and popped from the stack when they are closed.
>     For file pointers the fileno of the pointer is used.  On
>     Linux, when a file pointer is closed, the pointer value is
>     reset by the operating system.  This caused problems with
>     fileno and it is possible to cause segmentation violations.
> 
>     The fix is to replace existing "close then pop" sequences
>     with a macro that does a "pop then close" sequence on Linux
>     and a "close then pop" on other platforms.
> 
> I don't know if there was a similar fix made to Netbackup 5.x.
> 
> --andy.
> 
> --------------
> Andrew Sydelko
> Engineering Computer Network
> Purdue University
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu 
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
<Prev in Thread] Current Thread [Next in Thread>