Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and Solaris 11
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and Solaris 11
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
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, 0x) = 1 8205: accept(4, 0x, 0x, SOV_DEFAULT) = 5 8192: waitid(P_ALL, 0, 0x080461D0, WEXITED|WTRAPPED|WSTOPPED|WCONTINUED) (sleeping...) 8203: sigsuspend(0x08047220) (sleeping...) 8207/1: pollsys(0x, 0, 0x080427F8, 0x) = 0 8207/2: pollsys(0xFC1FDEB0, 1, 0xFC1FDE78, 0x) (sleeping...) 8205: pollsys(0x080B9008, 2, 0x080471D8, 0x) (sleeping...) 8207/1: pollsys(0x, 0, 0x080427F8, 0x) (sleeping...) 8207/1: pollsys(0x, 0, 0x080427F8, 0x) = 0 8207/1: pollsys(0x, 0, 0x080427F8, 0x) (sleeping...) 8207/1: pollsys(0x, 0, 0x080427F8, 0x) = 0 8207/1: pollsys(0x, 0, 0x080427F8, 0x) (sleeping...) 8207/1: pollsys(0x, 0, 0x080427F8, 0x) = 0 8207/1: pollsys(0x, 0, 0x080427F8, 0x) (sleeping...) 8207/1: pollsys(0x,
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and Solaris 11
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
