I've built/installed Tomcat 7.0.29 from source on linux/64.
I've setup an init.d using jsvc launch, loosely based on the src-bundled
daemon.sh script.
@ tomcat service launch, using out-of-the-box config for now, I see two
listeners on ONE pid,
netstat -pan --tcp | grep jsvc
ps is showing threads as processes, which occurs with some versions of
Linux kernel. The listeners are 2 different threads: an AJP on 8009 and an
HTTP on 8080.
On Mon, Jul 23, 2012 at 12:46 PM, k9...@operamail.com wrote:
I've built/installed Tomcat 7.0.29 from source on linux/64.
I've setup
Hi
On Mon, Jul 23, 2012, at 01:10 PM, Jeff Beard wrote:
ps is showing threads as processes, which occurs with some versions of
Linux kernel. The listeners are 2 different threads: an AJP on 8009 and
an
HTTP on 8080.
Ok, so that sounds like one PID per thread, at least according to ps on
this
Sorry, I didn't read you email close enough and said something stupid. It
appears that you are not seeing multiple threads as procs rather I think
it's a jsvc parent/child pair. It looks like the output of 'ps ax' it
doesn't show the parent PID. I use ps -ef which shows the parent ID. Try
that and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
To whom it mat concern,
On 7/23/12 2:46 PM, k9...@operamail.com wrote:
I've built/installed Tomcat 7.0.29 from source on linux/64.
Why did you bother to build Tomcat at all? I can see building the
daemon component, but building Tomcat itself is
On Mon, Jul 23, 2012, at 04:15 PM, Christopher Schultz wrote:
netstat -pan --tcp | grep jsvc tcp0 0 :::8080
:::* LISTEN 30891/jsvc.exec tcp0 0 :::8009
:::* LISTEN 30891/jsvc.exec
jsvc's job is to allow the controlled process to open ports, so all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
To whom it may concern,
On 7/23/12 4:37 PM, k9...@operamail.com wrote:
Try this:
$ ps afx
Then, look at the output for 'jsvc' and you should see *three*
linked processes. Since you only looked for 'jsvc' you aren't
seeing the expected 3rd
No other instance of 'java', 'jsvc' or 'tomcat' in the output.
Hm. Re-reading the commons-daemon page, it looks like maybe the
launcher process exits shortly after launch, leaving only two
long-running processes: the controlling process (the one in the
fork()/wait() loop) and the
