This wouldn't be a problem backing up the shadow password file.  It's
trying to use passwd file lookups (which when running as root will
consult /etc/security/passwd too) and dying in there somewhere.

It also shouldn't be files owned by UIDs not in the passwd file.  I
have a pair of servers with about a million files between them that
are owned by 35,000 UIDs not in the passwd file (though still using
the 3.1 client at the moment).

To me, this says the shadow file is corrupt somehow.  TSM is probably
doing a lookup on the owner of one of the files it's backing up.  Of
course, a corrupt shadow file shouldn't cause TSM to coredump, so a
call should still be opened with Tivoli/IBM.

Try running "pwdck -n ALL" and see what it reports.  Or manually go
take a look at /etc/security/passwd to see if there is something in
there that looks bogus.

Good luck!
=Dave

David Longo wrote:
>
> The shadow passwd file on AIX is /etc/security/passwd.  I would check all the 
> permissions etc. on this file with some of my other AIX clients and see if 
> there is any variance.
>
> I am not aware of *SM doing any checks on files other than - can the user 
> doing backups access that file and is it newer than the one laready backed , 
> etc.  However maybe it does do something.
>
> Try excluding this file or the /etc/security directory - Exclude 
> /etc/security/*
> and see if problem still happens.  Does the sched log show what 
> file/filesystem was being backed up when failure occurs?
>
> A few thoughts.....
>
> >>> rbs AT BU DOT EDU 03/14/01 11:55AM >>>
> > 03/14/01   17:02:39 B/A Txn Consumer thread, fatal error, signal 11
> > 03/14/01   17:02:39   0xD01C8C08 shadow_pass_r
> > 03/14/01   17:02:39   0xD01C8930 shadow_chk_r
>
> The signal 11 is obviously a Segmentation Fault, which is a sofware
> defect that should be reported to Tivoli Support for resolution.
> Looks like it is doing password lookups at the time.  It might be
> the case it is being thrown off by files in the file system having
> a UID but no corresponding user in the passwd file, as is common
> when usernames are retired from the passwd file but not all their
> files are addressed, to reassign them.  You might want to run the
> 'find' command with the -nouser option and see if there are any
> such files, to supplement the problem resolution with that info.
>
>   Richard Sims, BU
>


--
Hello World.                                    David Bronder - Systems Admin
Hello World.                                    David Bronder - Systems Admin
Segmentation Fault                                     ITS-SPA, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder AT uiowa 
DOT edu