Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of awang@ptc.com designates
 12.11.148.84 as permitted sender)
Message-ID: <51269C2C.3060307@ptc.com>
Date: Thu, 21 Feb 2013 16:14:04 -0600
From: Andy Wang <awang@ptc.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: <users@tomcat.apache.org>
Subject: Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and
 Solaris 11
References: <5122A185.6080408@ptc.com> <5123177A.2050100@apache.org>
 <51239BE5.1010701@ptc.com> <5123B2C0.8010001@kippdata.de>
In-Reply-To: <5123B2C0.8010001@kippdata.de>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

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