You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Gilles Maurice <gi...@snowsoftware.com.INVALID> on 2023/05/10 21:06:59 UTC

Setting service parameters not work in Tomcat 8.5.85+

Hello,

Our product currently uses Tomcat 8.5.83. We wanted to upgrade to Tomcat 8.5.88 but our product fails to start up with this version.

From my research I was able to determine the following facts:
- Upgrade to 8.5.84 works fine
- Upgrade to 8.5.85+ fails
- Our product uses "tomcat8.exe //US/vlm" to update the service parameters (vlm is the internal name of our product)
- with 8.5.85, calling the following command works fine: tomcat8.exe //US/vlm --Description myDescription
- setting java parameters don't work however, for example this command fails: tomcat8.exe //US/vlm --JvmMs 128
- when running the command above, tomcat8.exe does not display an error but the service is not updated
- the documentation at https://tomcat.apache.org/tomcat-8.5-doc/windows-service-howto.html indicates that the java update parameters are not set when in exe mode but ours is in jvm mode. For example, the following command will not set the JvmMs value: tomcat8.exe //US/vlm --Jvm auto --StartMode jvm --StopMode jvm --JvmMs 128

Does anyone have any info on how to get around this?
Otherwise, can someone direct me to the source code for tomcat8.exe so I can see if I can find the cause of this issue myself?

Thank-you,

Gilles Maurice

Software Designer

gilles.maurice@snowsoftware.com



[cid:f79d4ed5-1f86-4f32-b4e2-4badac630540]
Snow Software | 515 Legget Dr #300, Kanata, ON K2K 3G4
www.snowsoftware.com<http://www.snowsoftware.com/>




Re: Setting service parameters not work in Tomcat 8.5.85+

Posted by Gilles Maurice <gi...@snowsoftware.com.INVALID>.
Thanks do much for the quick reply, your response set me in the right direction to help diagnose the issue further.

In case you or others are interested here is the description of the issue and the workaround...

As of Tomcat 8.5.85, when setting jvm parameters, tomcat8.exe is validating if the default --LogPath of %SystemRoot%\System32\LogFiles\Apache is accessible for read/write.
In our test environment this is not the case. To make matters worse, our installer did not display the error message generated by tomcat8 so it made diagnosing the issue more difficult.

The workaround was to simply set a --LogPath to a folder that we know is read/write.

Thanks again for your help,
Gilles
________________________________
From: Mark Thomas <ma...@apache.org>
Sent: Thursday, May 11, 2023 8:50 AM
To: users@tomcat.apache.org <us...@tomcat.apache.org>
Subject: Re: Setting service parameters not work in Tomcat 8.5.85+

[EXTERNAL] This email originated from outside of the organization. Do not click links or open attachments unless you recognize and trust the sender's email address.

[You don't often get email from markt@apache.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

On 10/05/2023 22:06, Gilles Maurice wrote:
> Hello,
>
> Our product currently uses Tomcat 8.5.83. We wanted to upgrade to Tomcat
> 8.5.88 but our product fails to start up with this version.
>
>  From my research I was able to determine the following facts:
> - Upgrade to 8.5.84 works fine
> - Upgrade to 8.5.85+ fails
> - Our product uses "tomcat8.exe //US/vlm" to update the service
> parameters (vlm is the internal name of our product)
> - with 8.5.85, calling the following command works fine: tomcat8.exe
> //US/vlm --Description myDescription
> - setting java parameters don't work however, for example this command
> fails: tomcat8.exe //US/vlm --JvmMs 128
> - when running the command above, tomcat8.exe does not display an error
> but the service is not updated
> - the documentation at
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomcat.apache.org%2Ftomcat-8.5-doc%2Fwindows-service-howto.html&data=05%7C01%7Cgilles.maurice%40snowsoftware.com%7C98892c73af2f4fd9325608db521eab50%7Cd76c28a10b62484998fd8cf2516370ce%7C0%7C0%7C638194063892271630%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=g%2F0iQIGr72QQi8ysUznER16PuIKrXAKWnrr8qkKQTZM%3D&reserved=0<https://tomcat.apache.org/tomcat-8.5-doc/windows-service-howto.html>
> indicates that the java update parameters are not set when in exe mode
> but ours is in jvm mode. For example, the following command will not set
> the JvmMs value: tomcat8.exe //US/vlm --Jvm auto --StartMode jvm
> --StopMode jvm --JvmMs 128
>
> Does anyone have any info on how to get around this?

I am unable to recreate the problem described.

tomcat8.exe //US/Tomcat8 --JvmMs 128

works for me with a clean Tomcat installation.

How are you determining if the service is updated?

> Otherwise, can someone direct me to the source code for tomcat8.exe so I
> can see if I can find the cause of this issue myself?

You want Commons Daemon. Tomcat 8.5.85 upgraded from 1.3.2 to 1.3.3.

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcommons-daemon&data=05%7C01%7Cgilles.maurice%40snowsoftware.com%7C98892c73af2f4fd9325608db521eab50%7Cd76c28a10b62484998fd8cf2516370ce%7C0%7C0%7C638194063892271630%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9bQdJRbAebm3W5yFc4kCR9%2B5bVs47l8KrCIZVgjzHTk%3D&reserved=0<https://github.com/apache/commons-daemon>

Tomcat8.exe is a renamed prunsrv.exe

Tomcat8w.exe is a renamed prunmgr.exe


Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


AW: Java Agent and Tomcat shutdown

Posted by "Thomas Hoffmann (Speed4Trade GmbH)" <Th...@speed4trade.com.INVALID>.
Hello Peter,

> -----Ursprüngliche Nachricht-----
> Von: logo@kreuser.name <lo...@kreuser.name>
> Gesendet: Donnerstag, 11. Mai 2023 16:16
> An: Tomcat Users List <us...@tomcat.apache.org>
> Betreff: Re: Java Agent and Tomcat shutdown
> 
> Hi Thomas
> 
> > Am 11.05.2023 um 16:05 schrieb Thomas Hoffmann (Speed4Trade GmbH)
> <Th...@speed4trade.com.INVALID>:
> >
> > Hello,
> >
> > we are using a java agent to start a listening process (JMX proxy).
> >
> > The systemd file for tomcat looks like (snippet):
> > JAVA_OPTS=... -javaagent:/opt/runtime/jmxagent/jmxagent.jar
> > -Dorg.goktay.rmiregistry.port=15000 -Dorg.goktay.rmiserver.port=15001
> 
> 
> I do think that setting JAVA_OPTS is triggering this behavior: EVERY java
> process contains this rmi server with this conflicting port.
> 
> The way to go is using CATALINA_OPTS. The options go only into the start-
> process...
 
You are completely right. Everything makes sense now 😊
Thanks for the quick help!
Much appreciated!

> HTH
> 
> Peter
> 
> > ExecStart=/opt/apache-tomcat/bin/catalina.sh run
> > ExecStop=/opt/apache-tomcat/bin/catalina.sh stop 60
> >
> > When starting the service, everything works fine and the java agent is
> accessible via the opened port 15000.
> >
> > However, when stopping tomcat, it seems that a java process is started and
> tries to open the same port again:
> > 2670]: Exception in thread "main" java.lang.reflect.InvocationTargetException
> >        at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> >        at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod
> AccessorImpl.java:77)
> >        at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin
> gMethodAccessorImpl.java:43)
> >        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> >        at
> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(In
> strumentationImpl.java:493)
> >        at
> > java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPre
> > main(InstrumentationImpl.java:503)
> > Caused by: java.rmi.server.ExportException: Port already in use: 15000;
> nested exception is:
> >        java.net.BindException: Address already in use
> >        at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:346)
> >        at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:2
> 43)
> >        at
> java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:415
> )
> >        at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
> >        at
> java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:2
> 35)
> >        at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:223)
> >        at java.rmi/sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:208)
> >        at
> java.rmi/java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:20
> 3)
> >        at org.goktay.jmx.JMXAgent.premain(JMXAgent.java:33)
> >        ... 6 more
> > Caused by: java.net.BindException: Address already in use
> >        at java.base/sun.nio.ch.Net.bind0(Native Method)
> >        at java.base/sun.nio.ch.Net.bind(Net.java:555)
> >        at java.base/sun.nio.ch.Net.bind(Net.java:544)
> >        at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643)
> >        at java.base/java.net.ServerSocket.bind(ServerSocket.java:388)
> >        at java.base/java.net.ServerSocket.<init>(ServerSocket.java:274)
> >        at java.base/java.net.ServerSocket.<init>(ServerSocket.java:167)
> >        at
> java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createServerSocket(TCP
> DirectSocketFactory.java:45)
> >        at
> java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java
> :673)
> >        at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
> >        ... 14 more
> > *** java.lang.instrument ASSERTION FAILED ***: "result" with message
> > agent load/premain call failed at
> > src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 422
> >
> > The premain method is entered again and of course the port is already used.
> > Is there a way to stop tomcat without re-entering the java agent?
> > Using shutdown.sh shows the same problem.
> >
> > Thanks in advance!
> > Thomas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org


Re: Java Agent and Tomcat shutdown

Posted by lo...@kreuser.name.
Hi Thomas

> Am 11.05.2023 um 16:05 schrieb Thomas Hoffmann (Speed4Trade GmbH) <Th...@speed4trade.com.INVALID>:
> 
> Hello,
> 
> we are using a java agent to start a listening process (JMX proxy).
> 
> The systemd file for tomcat looks like (snippet):
> JAVA_OPTS=... -javaagent:/opt/runtime/jmxagent/jmxagent.jar -Dorg.goktay.rmiregistry.port=15000 -Dorg.goktay.rmiserver.port=15001


I do think that setting JAVA_OPTS is triggering this behavior: EVERY java process contains this rmi server with this conflicting port.

The way to go is using CATALINA_OPTS. The options go only into the start-process...

HTH 

Peter

> ExecStart=/opt/apache-tomcat/bin/catalina.sh run
> ExecStop=/opt/apache-tomcat/bin/catalina.sh stop 60
> 
> When starting the service, everything works fine and the java agent is accessible via the opened port 15000.
> 
> However, when stopping tomcat, it seems that a java process is started and tries to open the same port again:
> 2670]: Exception in thread "main" java.lang.reflect.InvocationTargetException
>        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>        at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:493)
>        at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:503)
> Caused by: java.rmi.server.ExportException: Port already in use: 15000; nested exception is:
>        java.net.BindException: Address already in use
>        at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:346)
>        at java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243)
>        at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:415)
>        at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
>        at java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:235)
>        at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:223)
>        at java.rmi/sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:208)
>        at java.rmi/java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:203)
>        at org.goktay.jmx.JMXAgent.premain(JMXAgent.java:33)
>        ... 6 more
> Caused by: java.net.BindException: Address already in use
>        at java.base/sun.nio.ch.Net.bind0(Native Method)
>        at java.base/sun.nio.ch.Net.bind(Net.java:555)
>        at java.base/sun.nio.ch.Net.bind(Net.java:544)
>        at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643)
>        at java.base/java.net.ServerSocket.bind(ServerSocket.java:388)
>        at java.base/java.net.ServerSocket.<init>(ServerSocket.java:274)
>        at java.base/java.net.ServerSocket.<init>(ServerSocket.java:167)
>        at java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createServerSocket(TCPDirectSocketFactory.java:45)
>        at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:673)
>        at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
>        ... 14 more
> *** java.lang.instrument ASSERTION FAILED ***: "result" with message agent load/premain call failed at src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 422
> 
> The premain method is entered again and of course the port is already used.
> Is there a way to stop tomcat without re-entering the java agent?
> Using shutdown.sh shows the same problem.
> 
> Thanks in advance!
> Thomas
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Java Agent and Tomcat shutdown

Posted by "Thomas Hoffmann (Speed4Trade GmbH)" <Th...@speed4trade.com.INVALID>.
Hello,

we are using a java agent to start a listening process (JMX proxy).

The systemd file for tomcat looks like (snippet):
  JAVA_OPTS=... -javaagent:/opt/runtime/jmxagent/jmxagent.jar -Dorg.goktay.rmiregistry.port=15000 -Dorg.goktay.rmiserver.port=15001
  ExecStart=/opt/apache-tomcat/bin/catalina.sh run
  ExecStop=/opt/apache-tomcat/bin/catalina.sh stop 60

When starting the service, everything works fine and the java agent is accessible via the opened port 15000.

However, when stopping tomcat, it seems that a java process is started and tries to open the same port again:
2670]: Exception in thread "main" java.lang.reflect.InvocationTargetException
         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
         at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
         at java.base/java.lang.reflect.Method.invoke(Method.java:568)
         at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:493)
         at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:503)
 Caused by: java.rmi.server.ExportException: Port already in use: 15000; nested exception is:
         java.net.BindException: Address already in use
         at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:346)
         at java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243)
         at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:415)
         at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
         at java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:235)
         at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:223)
         at java.rmi/sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:208)
         at java.rmi/java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:203)
         at org.goktay.jmx.JMXAgent.premain(JMXAgent.java:33)
         ... 6 more
 Caused by: java.net.BindException: Address already in use
         at java.base/sun.nio.ch.Net.bind0(Native Method)
         at java.base/sun.nio.ch.Net.bind(Net.java:555)
         at java.base/sun.nio.ch.Net.bind(Net.java:544)
         at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643)
         at java.base/java.net.ServerSocket.bind(ServerSocket.java:388)
         at java.base/java.net.ServerSocket.<init>(ServerSocket.java:274)
         at java.base/java.net.ServerSocket.<init>(ServerSocket.java:167)
         at java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createServerSocket(TCPDirectSocketFactory.java:45)
         at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:673)
         at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
         ... 14 more
 *** java.lang.instrument ASSERTION FAILED ***: "result" with message agent load/premain call failed at src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 422

The premain method is entered again and of course the port is already used.
Is there a way to stop tomcat without re-entering the java agent?
Using shutdown.sh shows the same problem.

Thanks in advance!
Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Setting service parameters not work in Tomcat 8.5.85+

Posted by Mark Thomas <ma...@apache.org>.
On 10/05/2023 22:06, Gilles Maurice wrote:
> Hello,
> 
> Our product currently uses Tomcat 8.5.83. We wanted to upgrade to Tomcat 
> 8.5.88 but our product fails to start up with this version.
> 
>  From my research I was able to determine the following facts:
> - Upgrade to 8.5.84 works fine
> - Upgrade to 8.5.85+ fails
> - Our product uses "tomcat8.exe //US/vlm" to update the service 
> parameters (vlm is the internal name of our product)
> - with 8.5.85, calling the following command works fine: tomcat8.exe 
> //US/vlm --Description myDescription
> - setting java parameters don't work however, for example this command 
> fails: tomcat8.exe //US/vlm --JvmMs 128
> - when running the command above, tomcat8.exe does not display an error 
> but the service is not updated
> - the documentation at 
> https://tomcat.apache.org/tomcat-8.5-doc/windows-service-howto.html 
> indicates that the java update parameters are not set when in exe mode 
> but ours is in jvm mode. For example, the following command will not set 
> the JvmMs value: tomcat8.exe //US/vlm --Jvm auto --StartMode jvm 
> --StopMode jvm --JvmMs 128
> 
> Does anyone have any info on how to get around this?

I am unable to recreate the problem described.

tomcat8.exe //US/Tomcat8 --JvmMs 128

works for me with a clean Tomcat installation.

How are you determining if the service is updated?

> Otherwise, can someone direct me to the source code for tomcat8.exe so I 
> can see if I can find the cause of this issue myself?

You want Commons Daemon. Tomcat 8.5.85 upgraded from 1.3.2 to 1.3.3.

https://github.com/apache/commons-daemon

Tomcat8.exe is a renamed prunsrv.exe

Tomcat8w.exe is a renamed prunmgr.exe


Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org