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