Re: $$ broken??

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> The real question I have here is, why is $$ in rc.local giving me
>> the wrong value?
> It might be that some shell syntax that runs as a child doesn't
> update $$.  Things like loops with redirections and script with
> (...).

That's ugly.  I don't suppose there's a
${$_NO_REALLY_DAMMIT_I_WANT_THE_PID_THATS_ACTUALLY_RUNNING_NOW}?

And, yeah, that's probably it.  rc.local is run from /etc/rc.d/local,
which is not called local.sh and thus is run in a subshell.  Oddly,
it's run with ( set $_arg ; . $_file ) rather than just $_file $_arg;
it's almost as if someone were trying to break $$ within rc.d scripts.
Since I consider that implausible, this leads me to ask, next, why it's
done that way.

Furthermore, I would expect that to lead to just two processes, the
`main' shell and the one actually executing, and I'm seeing four.

>> Perhaps more importantly, what can I do to fix it?  Failing that, is
>> there some other tool I can use to give me the correct PID as a
>> workaround?
> Maybe: syctl proc.curproc.rlimit....

That would work for querying, but for changing, it will change the
sysctl process's limits, which won't have any lasting effect.

I've found a workaround, though it's a bit brittle.  It happens that
all sh processes extant at that point are running /etc/rc, so instead
of thispid=$$ I now do thispid="`/local/bin/findproc -p sh`" and hit
them all.  But of course this depends on none of the other things
started by that point leaving sh processes running.  I arguably should
use a different variable name now that it holds multiple PIDs....

Yet another casualty of the shattering of /etc/rc.  *grrr*

Come to think of it, that should be an effective workaround: put the
resource limit fiddling in /etc/rc instead of /etc/rc.local.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B