[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: $$ broken??
>> 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
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
> 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
Main Index |
Thread Index |