user in update and locks up a report being run

Shane Gray shane at satsof.com.au
Thu Dec 23 14:59:07 PST 2010


> -----Original Message-----
> From: 
> filepro-list-bounces+fplist=satsof.com.au at lists.celestial.com 
> [mailto:filepro-list-bounces+fplist=satsof.com.au at lists.celest
ial.com] On Behalf Of Fairlight
> Sent: Friday, 24 December 2010 3:55 AM
> To: filepro-list at lists.celestial.com
> Subject: Re: user in update and locks up a report being run
> 
> Is it just me, or did Kenneth Brody say:
> > 
> > Not "owner of the PID" but "PID of the lock owner".
> 
> The PID of the lock owner is going to correspond to clerk, 
> report, etc.
> Thar PID will always be owned by filepro on linux, due to how 
> proc (or the
> underlying mechanics of the linux process table) handles SUID 
> processes.
> 
> SCO will show the UID for the PID.  Linux will show the EUID. 
>  Same way you
> look at `ps` and have one httpd owned by root, but all the 
> children are
> owned by whatever User is set to in Apache.
> 
> In terms of determining who is responsible for the locked 
> record, "PID of
> the lock owner" and "owner of the PID" are tightly bound.  You have to
> backtrace PPIDs to find the real user who owns the top-level 
> parent until
> you run out of PPIDs that make sense to trace to (since every 
> process will
> trace back to init).
> 

How about:

ps fp $pid -o "ruser=" -o "tty="

Where $pid is the "PID of the lock owner" (clerk/report).




More information about the Filepro-list mailing list