You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2008/11/21 21:14:56 UTC
Solaris shell
Attached is a patch, I'd like at least another two pairs of eyeballs before
applying to trunk and 1.3.
The first bit is most significant; /bin/sh on solaris simply sucks, and the
shell and invoked child simply do not handle pipes, signals and termination
correctly. /bin/ksh is far more robust, and I believe we should switch to
this instead.
Second bit; simply doc clarifications.
Third bit; it seems a bit nasty that an unrecognized arg causes a shell path
search, the preference aught to be as literal as possible. Since we had
already hit upon our match, this hack wastes a brief cycle for PROGRAM_PATH
invocations, and otherwise simply throws up on an unrecognized invocation.
Thoughts?
Re: Solaris shell
Posted by Rainer Jung <ra...@kippdata.de>.
> There is more research to do, but it's pretty obvious that /usr/sh is not
> the best choice. /bin/ksh seems a reasonable alternative.
>
> On failure (can't resolve libiconv.so.1 for rotatelogs) /usr/xpg4/bin/sh
> was miserable. It emitted several sig 5's into the error log every second
> as httpd tried to respawn the failed invocation. Insane.
>
> The best of all worlds seems to be if we added an option for apr_procattr_t
> that let the user pick-a-shell. I have some further thoughts on that which
> I'll explore as I work up patches to the piped logger code.
We ran into several problems with /bin/sh:
https://issues.apache.org/bugzilla/show_bug.cgi?id=38989 (httpd 1.3)
https://issues.apache.org/bugzilla/show_bug.cgi?id=40651 (httpd 2.x)
Since 2.5 years we always use patch the builds to use /usr/xpg4/bin/sh
and observed no problems. I agree, that your tests show that /bin/ksh
might be even better.
I can't add info about the LD_LIBRARY_PATH info, because we use
statically compiled support binaries.
Making the SHELL configurable would be nice.
Regards,
Rainer
Re: Solaris shell
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Here's the analysis on x86 solaris-10.x. Please note that the shell
I am actually using is /usr/local/bin/bash as I type the commands,
and that the startup script uses the shebang #!/bin/sh which may explain
some of the more interesting results, below.
No matter which, /bin/sh, /bin/ksh and /usr/xpg4/bin/sh all will refuse
to honor the LD_LIBRARY_PATH passed on when invoking the rotatelogs binary
process, at least directly. I am *guessing* that because we do not
invoke with a search-path option, so Solaris may be ignoring ld_library_path
library search paths. That's my current speculation.
At JimJag's suggestion, I built a workaround using a rotatelogs.sh script;
#!/bin/sh
set > $1
LD_LIBRARY_PATH="/path/to/apache2.0/lib:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH
/path/to/apache2.0/bin/rotatelogs $*
Note that I capture that.log as the envvars before forcing any
LD_LIBRARY_PATH (substitute 2.2 for 2.0 as needed) and launching
rotatelogs to create that.log.####, and that in each case I had
modified the shebang to use the same as I was testing from httpd/apr
(e.g. this is the original /bin/sh, and I replaced it with the
#!/bin/ksh and #!/usr/xpg4/bin/sh shells when I tested each of those
particular patches to apr).
This is what I uncloaked;
/bin/sh does work, with the script.
httpd 2.0.63/apr 0.9.17
PATH / LD_LIBRARY_PATH are NOT inherited
SHELL is absent (only IFS, MAILCHECK and OPTIND are set)
The process tree;
httpd (parent/root)
/bin/sh rotatelogs.sh
rotatelogs (binary)
httpd-2.2.9/apr 1.3.2
PATH and LD_LIBRARY_PATH are inherited
SHELL as /usr/local/bin/bash
The process tree;
httpd (parent/root)
/bin/sh -c rotatelogs.sh
/bin/sh rotatelogs.sh
rotatelogs (binary)
/bin/ksh essentially works
httpd 2.0.63/apr 0.9.17
PATH / LD_LIBRARY_PATH are NOT inherited
SHELL reports /bin/sh
httpd-2.2.9/apr 1.3.2
PATH and LD_LIBRARY_PATH are inherited
SHELL as /usr/local/bin/bash
Both process trees;
httpd (parent/root)
/bin/ksh rotatelogs.sh
rotatelogs (binary)
/usr/bin/xpg4/sh essentially works.
httpd 2.0.63/apr 0.9.17
PATH / LD_LIBRARY_PATH are NOT inherited
SHELL reports /bin/sh
httpd-2.2.9/apr 1.3.2
PATH and LD_LIBRARY_PATH are inherited
SHELL as /usr/local/bin/bash
Both process trees;
httpd (parent/root)
/usr/bin/xpg4/sh rotatelogs.sh
rotatelogs (binary)
We can dismiss bash since it's not terribly "solaris-ified", and is of
little interest for a lightweight shell. (bash is feature-rich and not
a centerpiece of the solaris world.)
There is more research to do, but it's pretty obvious that /usr/sh is not
the best choice. /bin/ksh seems a reasonable alternative.
On failure (can't resolve libiconv.so.1 for rotatelogs) /usr/xpg4/bin/sh
was miserable. It emitted several sig 5's into the error log every second
as httpd tried to respawn the failed invocation. Insane.
Also note we've lost error logging when we can't spin up the piped logger
process on httpd 2.2, nothing appears on the command line or in the
primary error log file, which I need to take a deeper look at.
The best of all worlds seems to be if we added an option for apr_procattr_t
that let the user pick-a-shell. I have some further thoughts on that which
I'll explore as I work up patches to the piped logger code.
Re: Solaris shell
Posted by Wes Garland <we...@page.ca>.
Will:
Sure, I'll test that in production as soon as I have the chance (might be a
little while -- big push on right now). I just noticed that my production
boxes are running 1.3.41 as well, so the patch should slide in pretty good.
These days I've been seeing about 1 hang every 2-3 weeks. When we had
slower hardware, it happened more often. Same thing when stuff gets busy....
so I'd better get the patch in before the Christmas break -- we normally
record pretty big peaks when the ball drops on New Year's eve. I'll patch
it to call "/bin/apr-sh" or something like that, and flip apr-sh at the
filesystem level to evaluate both shells.
Hmm. FWIW, the slower-hardware boxes also had more physical CPUs. (quad
UltraSparc-II vs. dual UltraSparc-IIIi).
Wes
On Fri, Nov 21, 2008 at 3:56 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net>wrote:
> Wes Garland wrote:
> > What's your current support-target for Solaris?
> >
> > /usr/xpg4/bin/sh might be another choice. Both installed virtually
> > everywhere. I don't know which is better.
> >...
> > So - if you suspect that changing the shell might improve my
> > experience..I'll be patching my local 1.2 even before 1.3 comes out. :)
>
> Hi Wes, yes; I've tried that before, going to try it again here now that
> you've reminded me ;-)
>
> Can I suggest you apply that first patch to production, testing both the
> /usr/ksh and /usr/xpg4/bin/sh - and let us know which is more effective
> in -your- experience?
>
> Nothing beats the real world, at least not until the Singularity :)
>
>
>
Re: Solaris shell
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Wes Garland wrote:
> What's your current support-target for Solaris?
>
> /usr/xpg4/bin/sh might be another choice. Both installed virtually
> everywhere. I don't know which is better.
>...
> So - if you suspect that changing the shell might improve my
> experience..I'll be patching my local 1.2 even before 1.3 comes out. :)
Hi Wes, yes; I've tried that before, going to try it again here now that
you've reminded me ;-)
Can I suggest you apply that first patch to production, testing both the
/usr/ksh and /usr/xpg4/bin/sh - and let us know which is more effective
in -your- experience?
Nothing beats the real world, at least not until the Singularity :)
Re: Solaris shell
Posted by Wes Garland <we...@page.ca>.
What's your current support-target for Solaris?
/usr/xpg4/bin/sh might be another choice. Both installed virtually
everywhere. I don't know which is better.
FWIW, this patch would affect me directly, every day, I create tens of
thousands of threads which turn around and spawn apps; quite often the apps
are shell scripts which receive input from pipes. That particular code has
give me grief for years (since apr 0.9.1?), I've never been able to figure
out which it mysteriously hangs every-now-and-then with a CPU busy-loop,
particularly on busy days, and it often (almost always? always?) happens
when I know the parent would have been due to handle a signal 15. Tested
Solaris 8 - 10, no real differences.
So - if you suspect that changing the shell might improve my
experience..I'll be patching my local 1.2 even before 1.3 comes out. :)
Wes
On Fri, Nov 21, 2008 at 3:14 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net>wrote:
> Attached is a patch, I'd like at least another two pairs of eyeballs before
> applying to trunk and 1.3.
>
> The first bit is most significant; /bin/sh on solaris simply sucks, and the
> shell and invoked child simply do not handle pipes, signals and termination
> correctly. /bin/ksh is far more robust, and I believe we should switch to
> this instead.
>
> Second bit; simply doc clarifications.
>
> Third bit; it seems a bit nasty that an unrecognized arg causes a shell
> path
> search, the preference aught to be as literal as possible. Since we had
> already hit upon our match, this hack wastes a brief cycle for PROGRAM_PATH
> invocations, and otherwise simply throws up on an unrecognized invocation.
>
> Thoughts?
>
>
Re: Solaris shell
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
>> Second bit; simply doc clarifications.
>
> Um, most of that looks like just whitespace and layout changes.
> Am I missing something?
Some whitespace, but also slight wording changes.
Re: Solaris shell
Posted by Nick Kew <ni...@webthing.com>.
On Fri, 21 Nov 2008 14:14:56 -0600
"William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> Attached is a patch, I'd like at least another two pairs of eyeballs
> before applying to trunk and 1.3.
>
> The first bit is most significant; /bin/sh on solaris simply sucks,
> and the shell and invoked child simply do not handle pipes, signals
> and termination correctly. /bin/ksh is far more robust, and I
> believe we should switch to this instead.
Isn't Solaris /bin/sh original-Bourne?
And doesn't that apply also to other non-GNU *x? It's been a while
since I've run a *BSD box, but I recollect /bin/sh as original-looking
Bourne, and replacing it ASAP on any *BSD box that comes my way.
I fear it may be us who are at fault for making invalid assumptions
about bash-isms in /bin/sh. But if your patch fixes real problems
as detailed in Rainer's bugs, then that makes sense.
> Second bit; simply doc clarifications.
Um, most of that looks like just whitespace and layout changes.
Am I missing something?
> Third bit; it seems a bit nasty that an unrecognized arg causes a
> shell path search, the preference aught to be as literal as
> possible. Since we had already hit upon our match, this hack wastes
> a brief cycle for PROGRAM_PATH invocations, and otherwise simply
> throws up on an unrecognized invocation.
Makes sense in principle. If the regression tests are happy, I'd say
go ahead in trunk and see if something breaks.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/