You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Andy Wang <aw...@ptc.com> on 2013/02/18 22:47:49 UTC
Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and Solaris
11
I'm having some problems getting the nsapi_redirect.dll working with
iPlanet 7.0.15 on solaris 11. The problem seems specifically related to
Solaris 11 and only if I try to install/run the server as root (using
webservd as the non-privileged user).
When I do so (and after enabling debug jk loglevel) during jk_init I see
the following messages in the jk log:
[Mon Feb 18 22:36:25.588 2013] [20669:1] [debug]
jk_init::jk_nsapi_plugin.c (337): jk_init, a second passed
repeated a bunch of times
and in the iPlanet error log the following:
[18/Feb/2013:22:37:24] failure (20669): CORE2254: Error running Init
function jk_init
Looking at the code:
s = systhread_start(SYSTHREAD_DEFAULT_PRIORITY,
0, init_workers_on_other_threads,
init_map);
for (sleep_cnt = 0; sleep_cnt < 60; sleep_cnt++) {
systhread_sleep(1000);
jk_log(logger, JK_LOG_DEBUG, "jk_init, a second passed");
if (init_on_other_thread_is_done) {
break;
}
}
I can find no evidence in the jklog that the
init_workers_on_other_threads thread actually started properly.
Here's the cute thing. It only happens on Solaris 11 with the server
run as root, and configured to run as a non-privileged user (any
non-privileged user has this issue)
If I execute startserv as the non-privileged user rather than root or do
this on Solaris 10, no problems.
Any ideas why systhread_start (this is an iPlanet NSAPI function) would
fail here as root?
Thanks,
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
Solaris 11
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> André,
>
> On 2/19/13 2:41 PM, André Warnier wrote:
>> I do not really understand the problem here, so this may be
>> relevant or not. I don't know, but I'm offering this free.
>
> OP is running iPlanet web server, which I believe has no relationship
> to Apache httpd. They may have similar startup techniques, though.
>
Ooops.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
Solaris 11
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 2/19/13 2:41 PM, André Warnier wrote:
> I do not really understand the problem here, so this may be
> relevant or not. I don't know, but I'm offering this free.
OP is running iPlanet web server, which I believe has no relationship
to Apache httpd. They may have similar startup techniques, though.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlEmztYACgkQ9CaO5/Lv0PC9uQCgtR2QGDJveb1FRSnORkJKl+hx
0wYAoKW1wCAeI5aoa9Je8TLNN2mItMEm
=SsNW
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
Solaris 11
Posted by André Warnier <aw...@ice-sa.com>.
Andy Wang wrote:
> On 02/19/2013 12:11 AM, Mladen Turk wrote:
>>
>> Did you tried to check the ulimit.
>> Seems like webservd once when switched to non privileged user cannot
>> create threads
>> either because of some security settings or lack of resources.
>>
>>
>
> I'm not so sure that this sequence is what's occurring.
> When the jk_init function is called, the non-privileged webservd process
> hasn't actually been spawned yet. As far as I can tell, it's still
> running within the root owned webservd parent process.
>
> So at this point, I don't think it's switched to the non-privileged user
> yet.
>
> Of course that still doesn't make sense why the root user wouldn't be
> able to create a thread with systhread_start.
>
Hi.
I do not really understand the problem here, so this may be relevant or not. I don't know,
but I'm offering this free.
I remember reading that in its start sequence, Apache first runs through a complete
startup sequence, reading all configuration files, loading and starting all add-on modules
etc.., all in the one startup "master" instance.
Then it throws everything away and immediately starts up again, goes again through the
same sequence and only then starts any "children" processes/threads.
Again if I remember correctly, this is done to allow Apache to check that all
configurations are correct, that all its required modules can be loaded etc., before
starting "for real". Maybe there is a clue in there for you. And maybe not.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
Solaris 11
Posted by Andy Wang <aw...@ptc.com>.
On 02/19/2013 12:11 AM, Mladen Turk wrote:
>
> Did you tried to check the ulimit.
> Seems like webservd once when switched to non privileged user cannot
> create threads
> either because of some security settings or lack of resources.
>
>
I'm not so sure that this sequence is what's occurring.
When the jk_init function is called, the non-privileged webservd process
hasn't actually been spawned yet. As far as I can tell, it's still
running within the root owned webservd parent process.
So at this point, I don't think it's switched to the non-privileged user
yet.
Of course that still doesn't make sense why the root user wouldn't be
able to create a thread with systhread_start.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
Solaris 11
Posted by Andy Wang <aw...@ptc.com>.
Oracle has agreed this is a bug. I've got a query into them to find out
what their ETA is.
Andy
On 05/03/2013 10:01 AM, Andy Wang wrote:
> On 05/02/2013 01:30 PM, Rainer Jung wrote:
>> Especially since the nsapi docs for systhread_start only tell us that
>> the prio is an int depending on the platform and the only other
>> source of information, nsapi.h only contains a single defined prio,
>> which is SYSTHREAD_DEFAULT_PRIORITY. The other constants
>> PR_PRIORITY_... are defined in nspr/prthread.h and are enum elements
>> of type PRThreadPriority which formally don't qualify as arguments to
>> systhread_start(int prio, int stksz, void (*fn)(void *), void *arg)
>> which needs an int.
>
> Yeah, I didn't go as far as dealing with the type differences when
> complaining to them but I'll make that point as well when I update the
> call later today.
>> I'm still not fully convinced, that PR_PRIORITY_* is correct and
>> isn't just working because PR_PRIORITY_NORMAL=1 is such a low number.
>> When you use PR_PRIORITY_NORMAL, can you see which priority the
>> created thread actually has? Probably using truss, since I think the
>> thread doesn't live long enough to be observable using "ps" with the
>> "-L" flag for threads and adding "pri" to the output format.
>> Nevertheless opening a bugzilla seems to be OK for tracking our
>> progress on this and making the problem publicly available. We might
>> later decide on resolving it as invalid though ;)
> Oh absolutely. I actually looked at the NSPR code and found the chunk
> that does the conversion and at initial glance it's basically the math
> used allows PR_PRIORITY_NORMAL and LOW to work.
>
> I went ahead and filed this in bugzilla:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=54923
>
> I'll push this with Oracle, but if they refuse to budge, does it seem
> like there'd be no choice but to include an ugly hack to use
> PR_PRIORITY_NORMAL or something else?
>
> Thanks,
> Andy
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
Solaris 11
Posted by Andy Wang <aw...@ptc.com>.
On 05/02/2013 01:30 PM, Rainer Jung wrote:
> Especially since the nsapi docs for systhread_start only tell us that
> the prio is an int depending on the platform and the only other source
> of information, nsapi.h only contains a single defined prio, which is
> SYSTHREAD_DEFAULT_PRIORITY. The other constants PR_PRIORITY_... are
> defined in nspr/prthread.h and are enum elements of type
> PRThreadPriority which formally don't qualify as arguments to
> systhread_start(int prio, int stksz, void (*fn)(void *), void *arg)
> which needs an int.
Yeah, I didn't go as far as dealing with the type differences when
complaining to them but I'll make that point as well when I update the
call later today.
> I'm still not fully convinced, that PR_PRIORITY_* is correct and isn't
> just working because PR_PRIORITY_NORMAL=1 is such a low number. When
> you use PR_PRIORITY_NORMAL, can you see which priority the created
> thread actually has? Probably using truss, since I think the thread
> doesn't live long enough to be observable using "ps" with the "-L"
> flag for threads and adding "pri" to the output format. Nevertheless
> opening a bugzilla seems to be OK for tracking our progress on this
> and making the problem publicly available. We might later decide on
> resolving it as invalid though ;)
Oh absolutely. I actually looked at the NSPR code and found the chunk
that does the conversion and at initial glance it's basically the math
used allows PR_PRIORITY_NORMAL and LOW to work.
I went ahead and filed this in bugzilla:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54923
I'll push this with Oracle, but if they refuse to budge, does it seem
like there'd be no choice but to include an ugly hack to use
PR_PRIORITY_NORMAL or something else?
Thanks,
Andy
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
Solaris 11
Posted by Rainer Jung <ra...@kippdata.de>.
On 02.05.2013 18:46, Andy Wang wrote:
> I've also confirmed that PR_PRIORITY_HIGH also fails but
> PR_PRIORITY_NORMAL is fine.
>
> I'm pushing oracle to accept that is is a bug. It is completely
> inappropriate for what appears to be a perfectly proper constant,
> SYSTHREAD_DEFAULT_PRIORITY, to map to something ilegal on Solaris 11.
Especially since the nsapi docs for systhread_start only tell us that
the prio is an int depending on the platform and the only other source
of information, nsapi.h only contains a single defined prio, which is
SYSTHREAD_DEFAULT_PRIORITY.
The other constants PR_PRIORITY_... are defined in nspr/prthread.h and
are enum elements of type PRThreadPriority which formally don't qualify
as arguments to
systhread_start(int prio, int stksz, void (*fn)(void *), void *arg)
which needs an int.
> Do you guys think this is worth a bugzilla report to track and consider
> changing jk_nsapi_plugin.c to use the NSPR PR_PRIORITY_* values or is it
> better to wait and see if Oracle fixes their code?
I'm still not fully convinced, that PR_PRIORITY_* is correct and isn't
just working because PR_PRIORITY_NORMAL=1 is such a low number.
When you use PR_PRIORITY_NORMAL, can you see which priority the created
thread actually has? Probably using truss, since I think the thread
doesn't live long enough to be observable using "ps" with the "-L" flag
for threads and adding "pri" to the output format.
Nevertheless opening a bugzilla seems to be OK for tracking our progress
on this and making the problem publicly available. We might later decide
on resolving it as invalid though ;)
> The response times I'm getting from them aren't great and they haven't
> acknowledged my requests that this be considered a bug the 2 or 3 times
> I've asked.
Well known problem, though I'm positively surprised you got such a
technically precise answer.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
Solaris 11
Posted by Andy Wang <aw...@ptc.com>.
I'm redirecting this to the dev list. I hope that's okay as I think this
is a bit more appropriate for developers rather than users.
I got a response from Oracle finally.
@ When running as root, the provided priority of SYSTHREAD_DEFAULT_PRIORITY
@ gets cast to an NSPR value of PR_PRIORITY_URGENT, which is finally
mapped to
@ a native priority value of 85, which in turn happens to be outside the
@ allowed priority ranges as per system configuration. The provided priority
@ value is unused when running as non-root, and hence the issue is not seen.
@ .
@ In more detail:
@ .
@ This issue happens due to the specified thread priority falling
outside the
@ configured limits in the system. "priocntl -l" displays the priority
ranges
@ allowed:
@ .
@ ...
@ TS (Time Sharing)
@ Configured TS User Priority Range: -60 through 60
@ ...
@ .
@ The systhread_start() API internally calls NSPR's PR_CreateThread().
@ The value of SYSTHREAD_DEFAULT_PRIORITY is 16, and this is cast to the
NSPR
@ priority of PR_PRIORITY_URGENT.
@ .
@ PR_CreateThread() ultimately calls pthread_create(). Before doing so,
@ PR_CreateThread() updates the new thread's attributes with the provided
@ priority, and more importantly, this is done only if root privileges are
@ available. In the case of a non-root user, the provided priority is
not used.
@ .
@ Now the problem with PR_PRIORITY_URGENT is the following: NSPR maps
the same
@ to a native priority number (85) before using it to update the new
thread's
@ attributes. 85 is outside the allowed priority ranges as reported by
@ "priocntl -l", and hence the pthread_create() ends up failing.
@ .
@ The customer has the following options:
@ .
@ 1. Use PR_PRIORITY_LOW instead of SYSTHREAD_DEFAULT_PRIORITY.
@ PR_PRIORITY_NORMAL might work, too.
@ 2. Check with Solaris team on how to change the system configuration
to tweak
@ the allowed range of thread priorities
I've also confirmed that PR_PRIORITY_HIGH also fails but
PR_PRIORITY_NORMAL is fine.
I'm pushing oracle to accept that is is a bug. It is completely
inappropriate for what appears to be a perfectly proper constant,
SYSTHREAD_DEFAULT_PRIORITY, to map to something ilegal on Solaris 11.
Do you guys think this is worth a bugzilla report to track and consider
changing jk_nsapi_plugin.c to use the NSPR PR_PRIORITY_* values or is it
better to wait and see if Oracle fixes their code?
The response times I'm getting from them aren't great and they haven't
acknowledged my requests that this be considered a bug the 2 or 3 times
I've asked.
Andy
On 02/21/2013 04:14 PM, Andy Wang wrote:
> On 02/19/2013 11:13 AM, Rainer Jung wrote:
>> It will be tedious, but if we want to check whether the OS disallows
>> some syscalls when running as suid under root, then truss should provide
>> insight.
>>
>> So run iPlanet (the iPlanet start script) under truss -f -o
>> /some/path/tr.out once in the working config and once in the non-working
>> one and try to find differences w.r.t. to syscalls that return an error.
>>
>> Once you know what you are looking after, the additional truss flags "-v
>> all -w all -r all" will provide aditional insight (and a huge volume of
>> output).
>>
>>
> I was hoping to avoid truss and that someone else had experienced
> this, or had an idea of what might be new in Solaris 11 that would
> cause this :)
>
> This is in the case where it works:
> 8435/2: read(7, 0xFC1FDF50, 4096) Err#11 EAGAIN
> 8435/3: lwp_create() (returning as new lwp ...) = 0
> 8435/3: setustack(0xFC8D0AA0)
> 8435/3: schedctl() =
> 0xFC975020
> 8435/3: open("/etc/netconfig", O_RDONLY) = 13
> 8435/3: fstat64(13, 0xFC07F720) = 0
> 8435/3: fstat64(13, 0xFC07F630) = 0
>
> thread 3 was created and that's what does the systhread_start stuff.
>
> In the case where it doesn't work:
> 8207/2: read(8, 0xFC1FDF50, 4096) Err#11 EAGAIN
> 8205: pollsys(0x080B9008, 1, 0x080471D8, 0x00000000) = 1
> 8205: accept(4, 0x00000000, 0x00000000, SOV_DEFAULT) = 5
> 8192: waitid(P_ALL, 0, 0x080461D0,
> WEXITED|WTRAPPED|WSTOPPED|WCONTINUED) (sleeping...)
> 8203: sigsuspend(0x08047220) (sleeping...)
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
> 8207/2: pollsys(0xFC1FDEB0, 1, 0xFC1FDE78, 0x00000000)
> (sleeping...)
> 8205: pollsys(0x080B9008, 2, 0x080471D8, 0x00000000) (sleeping...)
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000)
> (sleeping...)
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000)
> (sleeping...)
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000)
> (sleeping...)
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000)
> (sleeping...)
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
> 8207/2: pollsys(0xFC1FDEB0, 1, 0xFC1FDE78, 0x00000000) = 0
>
> So something is definitely preventing the systhread_start call to even
> get as far as the system call to lwp_create.
>
> Unfortunately, this is now quite a bit beyond me. Might have to
> figure out our partner contacts at oracle to see what's up.
>
> Andy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
Solaris 11
Posted by Andy Wang <aw...@ptc.com>.
On 02/19/2013 11:13 AM, Rainer Jung wrote:
> It will be tedious, but if we want to check whether the OS disallows
> some syscalls when running as suid under root, then truss should provide
> insight.
>
> So run iPlanet (the iPlanet start script) under truss -f -o
> /some/path/tr.out once in the working config and once in the non-working
> one and try to find differences w.r.t. to syscalls that return an error.
>
> Once you know what you are looking after, the additional truss flags "-v
> all -w all -r all" will provide aditional insight (and a huge volume of
> output).
>
>
I was hoping to avoid truss and that someone else had experienced this,
or had an idea of what might be new in Solaris 11 that would cause this :)
This is in the case where it works:
8435/2: read(7, 0xFC1FDF50, 4096) Err#11 EAGAIN
8435/3: lwp_create() (returning as new lwp ...) = 0
8435/3: setustack(0xFC8D0AA0)
8435/3: schedctl() = 0xFC975020
8435/3: open("/etc/netconfig", O_RDONLY) = 13
8435/3: fstat64(13, 0xFC07F720) = 0
8435/3: fstat64(13, 0xFC07F630) = 0
thread 3 was created and that's what does the systhread_start stuff.
In the case where it doesn't work:
8207/2: read(8, 0xFC1FDF50, 4096) Err#11 EAGAIN
8205: pollsys(0x080B9008, 1, 0x080471D8, 0x00000000) = 1
8205: accept(4, 0x00000000, 0x00000000, SOV_DEFAULT) = 5
8192: waitid(P_ALL, 0, 0x080461D0,
WEXITED|WTRAPPED|WSTOPPED|WCONTINUED) (sleeping...)
8203: sigsuspend(0x08047220) (sleeping...)
8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
8207/2: pollsys(0xFC1FDEB0, 1, 0xFC1FDE78, 0x00000000) (sleeping...)
8205: pollsys(0x080B9008, 2, 0x080471D8, 0x00000000) (sleeping...)
8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) (sleeping...)
8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) (sleeping...)
8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) (sleeping...)
8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) (sleeping...)
8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
8207/2: pollsys(0xFC1FDEB0, 1, 0xFC1FDE78, 0x00000000) = 0
So something is definitely preventing the systhread_start call to even
get as far as the system call to lwp_create.
Unfortunately, this is now quite a bit beyond me. Might have to figure
out our partner contacts at oracle to see what's up.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
Solaris 11
Posted by Rainer Jung <ra...@kippdata.de>.
On 19.02.2013 16:36, Andy Wang wrote:
> On 02/19/2013 12:11 AM, Mladen Turk wrote:
>> On 02/18/2013 10:47 PM, Andy Wang wrote:
>>>
>>> If I execute startserv as the non-privileged user rather than root or
>>> do this on Solaris 10, no problems.
>>> Any ideas why systhread_start (this is an iPlanet NSAPI function)
>>> would fail here as root?
>>>
>>
>> Did you tried to check the ulimit.
>> Seems like webservd once when switched to non privileged user cannot
>> create threads
>> either because of some security settings or lack of resources.
>>
> Yeah, sorry, I should have mentioned it.
> -u is 29995
> -n is 1024
> both are identical for the root role or the webservd user.
>
> I'm not that familiar with Solaris 11 and what they did to the root as a
> role instead of a regular user so I wasn't sure what other resource
> configuration to look at. What does confuse me though is the thread
> pool stuff in the webserver itself (as well as the built-in servlet
> engine) seem fully functional so this issue seems specific to the
> jk_init call to systhread_start.
It will be tedious, but if we want to check whether the OS disallows
some syscalls when running as suid under root, then truss should provide
insight.
So run iPlanet (the iPlanet start script) under truss -f -o
/some/path/tr.out once in the working config and once in the non-working
one and try to find differences w.r.t. to syscalls that return an error.
Once you know what you are looking after, the additional truss flags "-v
all -w all -r all" will provide aditional insight (and a huge volume of
output).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
Solaris 11
Posted by Andy Wang <aw...@ptc.com>.
On 02/19/2013 12:11 AM, Mladen Turk wrote:
> On 02/18/2013 10:47 PM, Andy Wang wrote:
>>
>> If I execute startserv as the non-privileged user rather than root or
>> do this on Solaris 10, no problems.
>> Any ideas why systhread_start (this is an iPlanet NSAPI function)
>> would fail here as root?
>>
>
> Did you tried to check the ulimit.
> Seems like webservd once when switched to non privileged user cannot
> create threads
> either because of some security settings or lack of resources.
>
Yeah, sorry, I should have mentioned it.
-u is 29995
-n is 1024
both are identical for the root role or the webservd user.
I'm not that familiar with Solaris 11 and what they did to the root as a
role instead of a regular user so I wasn't sure what other resource
configuration to look at. What does confuse me though is the thread
pool stuff in the webserver itself (as well as the built-in servlet
engine) seem fully functional so this issue seems specific to the
jk_init call to systhread_start.
Thanks,
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
Solaris 11
Posted by Mladen Turk <mt...@apache.org>.
On 02/18/2013 10:47 PM, Andy Wang wrote:
>
> If I execute startserv as the non-privileged user rather than root or do this on Solaris 10, no problems.
> Any ideas why systhread_start (this is an iPlanet NSAPI function) would fail here as root?
>
Did you tried to check the ulimit.
Seems like webservd once when switched to non privileged user cannot create threads
either because of some security settings or lack of resources.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org