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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
