We Keep Coding

Tomcat9 creates files in /tmp/systemd-private*** path instead of my given path [duplicate]

I'd like for my webapp which is deployed as a war ROOT.war to have write access to /var/www/html/static/images so that it can write uploaded and converted images to that folder so nginx can serve it statically. Currently it doesn't work and triggers a java.nio.file.FileSystemException exception together with the Filesystem is read-only message.
But the filesystem is not read-only and is in great condition. The folder has already been chmodded 777.
Extra info:
The tomcat setup is running on an Ubuntu 18.04 Azure VM with managed disk. The folder is residing on an Ext4 formatted drive

Let's start with: chmod 777 is great for testing, but absolutely unfit for the real world and you shouldn't get used to this setting. Rather set the owner/group correctly, before you give world write permissions.
Edit: A similar question just came up on the Tomcat mailing list, and Emmanuel Bourg pointed out that Debian Tomcat is sandboxed by systemd. Read your /usr/share/doc/tomcat9/README.Debian which contains this paragraph:
Tomcat is sandboxed by systemd and only has write access to the
following directories:
/var/lib/tomcat9/conf/Catalina (actually /etc/tomcat9/Catalina)
/var/lib/tomcat9/logs (actually /var/log/tomcat9)
/var/lib/tomcat9/webapps
/var/lib/tomcat9/work (actually /var/cache/tomcat9)
If write access to other directories is required the service settings
have to be overridden. This is done by creating an override.conf file
in /etc/systemd/system/tomcat9.service.d/ containing:
[Service]
ReadWritePaths=/path/to/the/directory/
The service has to be restarted afterward with:
systemctl daemon-reload
systemctl restart tomcat9
Edit 2022: Note that these are the 2019 paths - validate the file locations for later versions. From the comments to this answer (thank you to V H and Ng Sek Long) here are some updates:
In current Ubuntu file is here: sudo vi /etc/systemd/system/multi-user.target.wants/tomcat9.service – V H Feb 26, 2022 at 19:55
Mine (Ubuntu 20) is installed here /lib/systemd/system/tomcat9.service smh everybody use a different path. – Ng Sek Long Mar 28, 2022 at 8:36
End of edit, continuing with the passage that didn't solve OP's problem, but should stay in:
If - all things tested - Tomcat should have write access to that directory, but doesn't have it, the error message points me to an assumption: Could it be that
Tomcat is running as root?
The directory is mounted through NFS?
The default configuration for NFS is that root has no permissions whatsoever on that external filesystem (or was it no write-permission? this is ancient historical memory - look up "NFS root squash" to get the full story)
If this is a condition that matches what you are running, you should stop running Tomcat as root, and rather run it as an unprivileged user. Then you can set the permissions on the directory in question to be writeable by your tomcat-user, and readable by nginx, and you're done.
Running Tomcat as root is a recipe for disaster: You don't want a process that's available from the internet to run as root.
If these conditions don't meet your configuration: Elaborate on the configuration. I'd still stand by this description for others who might find this question/answer later.

Why is my Tomcat server throwing intermittent 404's when compiling JSP's?

I need help figuring out why a couple of my web applications are intermittently throwing 404 errors when trying to bring up a JSP. One of them has the JSP accessed directly and the other has a servlet that is forwarding to a JSP. The pages work most of the time, but occasionally will throw a 404. If the user refreshes their browser 1-3 times, the page starts working again without any changes required.
Here is a sample of the error as seen in the web browser (Chrome):
type: Status report
message: /app_root/my_page.jsp
description: The requested resource is not available
The problem seems to be related to recompiling the JSP pages. The .war file and expanded directory haven't changed. There are always three errors in the logs that correspond to each 404 error:
WARNING: Failed to delete generated class file [D:\Apache Software Foundation\Tomcat 7.0\work\Catalina\localhost\app_root\org\apache\jsp\my_005fpage_jsp.class]
May 19, 2015 6:32:24 AM org.apache.jasper.compiler.Compiler removeGeneratedFiles
WARNING: Failed to delete generated Java file [D:\Apache Software Foundation\Tomcat 7.0\work\Catalina\localhost\app_root\org\apache\jsp\my_005fpage_jsp.java]
May 19, 2015 6:32:24 AM org.apache.jasper.compiler.Compiler generateJava
WARNING: Failed to delete generated Java file [D:\Apache Software Foundation\Tomcat 7.0\work\Catalina\localhost\app_root\org\apache\jsp\my_005fpage_jsp.java]
I'm running Java 1.7 on Tomcat 7.0.53. Tomcat is running on a Windows 2008 R2 server.
Here is what I've tried so far, based on the information I've found from google. However, the 404's continue.
Disabled Windows indexing on the entire Tomcat directory
Turned off development mode in my production environment
Increased modificationTestInterval in my QA environment from the default (4 seconds) to 3600 (1 hour) [Note: it is currently set to 0 to try to help me reproduce the issue]
Changed the owner on the Tomcat work directory to be the same id as the id that the service is running as.
I am in the process of getting anti-virus turned off on the work directory to see if that helps.
While this issue is occurring on my prod and QA servers, it doesn't occur for me on my local Tomcat instance. In fact, I have yet to see the problem from my workstation even when running the QA and Prod applications. The issue has only been seen by other people.

The Tomcat container caches .java and .class files generated by the JSP parser, which are used by the web application. Sometimes these get corrupted or cannot be found. This may occur after a patch or upgrade that contains modifications to JSPs.
Solution is to just simply delete the work directory and restart the tomcat

I had the same problem after deploying a .war on our live server. These are the steps that I followed to solve the problem:
1) Shut down the tomcat server
2) Go to <your tomcat directory> -> work -> Catalina -> localhost -> <your project> -> org -> apache -> jsp ->
3) Manually delete both .class and .java
4) Delete the .war file and the deployed folder from the website that is having the issue on the webapps folder.
5) Export a new .war, and put it into the webapps folder.
6) Start up the tomcat service again.
Once the server is finished deploying, it will auto re-generate the deleted files in the "work" directory and the website should be available again without the intermittent 404 error.
I hope it works for you too.

Check the authority of this file or folder. Generally this problem is caused by lack of access to folders.

Websphere works when run but fails when debug

I'm using Intellij with WebSphere 8. When I run from within IDE the server works normally. When I try to run it in debug mode however, it fails with the following error:
C:\IBM\WebSphere\AppServer\profiles\AppSrv01\bin\generated_websphere_server_start_script.cmd
C:\IBM\WebSphere\AppServer\java\bin\java -Dfile.encoding=windows-1252 -classpath "C:\IBM\WebSphere\AppServer\runtimes\com.ibm.ws.admin.client_8.5.0.jar;C:\IBM\WebSphere\AppServer\plugins\com.ibm.ws.security.crypto.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA 13.1.3\plugins\webSphereIntegration\lib\webSphereIntegration.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA 13.1.3\plugins\JavaEE\lib\javaee-impl.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA 13.1.3\lib\openapi.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA 13.1.3\plugins\webSphereIntegration\lib\specifics\webSphereClientImpl.jar" com.intellij.javaee.oss.process.JavaeeProcess 62847 com.intellij.j2ee.webSphere.agent.WebSphereAgent
Error: JDWP agent already loaded - please check java command line options
[2014-08-11 01:58:59,248] Artifact x.ear: Server is not connected. Deploy is not available.
JVMJ9TI064E Agent initialization function Agent_OnLoad failed for library jdwp, return code -1
Detected server admin port: 8880
JVMJ9VM015W Initialization error for library j9jvmti26(-3): JVMJ9VM009E J9VMDllMain failed
Detected server http port: 9080
Disconnected from server
I tried almost everything I have no idea what the problem is. I did google it for several hours with no luck.
Do anyone know what this all is about and how can it be fixed?
Here is my server configuration:

Solution 1
unchecked the Pass environment variables check box and restart the server in debug mode. it should work properly.
Run --> Edit Configuration --> websphere server --> Startup/Conections tab
select debug, you will see the Pass environment variables check box. it need to be unchecked for debug to work.
Solution 2
if debug mode of websphere is working in eclipse and not working in intellij that reason i found out is debugging serverice on the websphere is already started and intellij is again trying to start the debggin service. so stop the service from websphere console (Servers > Server Types > WebSphere application servers > [serverName] > Debugging Service) and all the default configurations in intellij should work.

I had the same problem. Finally I figure it out. I hope this solution helps. I'm using Intellij idea 2019.1.3.. and WebSphere 8.5.5.13
check WebSphere start server script find debug env variable name (in my script (WebSphere\AppServer\bin\startServer.bat)
WAS_DEBUG)
add same debug option name to intelliJ IDEA
run- debug configuration environment tab.
Since default env variable is debug and cannot be overridden
check pass env variables
add WAS_DEBUG option as I did
or you can update WAS_DEBUG as DEBUG (same as default in IntelliJ) in server startup.bat script.
Both should work.

Pretty old, but i was able to experience too!
They will try to fix this now in: https://youtrack.jetbrains.com/issue/IDEA-193580

firstly, sorry if the translation is not good, I am Brazilian and I would like to share the solution I made.
First: Locate the file "startServer.bat in "WebSphere\AppServer\bin" and open it with any text editor.
Second: Search for the second incidence of the word "WAS_DEBUG" and replace it with "DEBUG", as shown in the image...
Third: In Intellij, go to the server settings and in the "Startup/Connection" tab, select debug.
Fourth: Now uncheck the "use default" checkbox in "Startup script" and point to the location of the "startServer.bat" file in the webSphere directory.
Fifth: Right on the left side of the checkbox, there is an option to enter a parameter. Click and a "Program Arguments" field will appear. Enter the server name, in my case it was "server1".
Okay, now just test
enter image description here
enter image description here

Apache tomcat7 as windows service

I am trying to create a windows service for Apache tomcat 7.0.45.
( in windows version 7)
I executed this :
C:/tomcat7/bin> service install Mytomcat7
Windows service has been created. but it wont start and throws "specific server error code 4".
Can you please help with the steps to create windows service.

I had the same problem!
Found out, that the service.bat didn't configure the service the right way. If you enable the logging from your service starter:
Then you'll see in your loggs something like:
[2014-02-19 16:40:35] [error] ( javajni.c:863 ) [ 2636] FindClass org/apache/catalina/startup/Bootstrap failed
[2014-02-19 16:40:35] [debug] ( javajni.c:964 ) [ 2636] Java Worker thread finished org/apache/catalina/startup/Bootstrap:main with status=3
[2014-02-19 16:40:35] [error] ( prunsrv.c:1183) [ 5000] Failed to start Java
[2014-02-19 16:40:35] [error] ( prunsrv.c:1536) [ 5000] ServiceStart returned 4
You'll notice that there is some classpath problem with the starter. In fact that's the problem! Your service.bat didn't configure the service the right way:
Note: You can also choose "Use default" above "Java Virtual Machine" to use whatever JVM is defined in JAVA_HOME
You'll need to set the classpath correctly:
c:\webclient\apache-tomcat\bin\tomcat-juli.jar;c:\webclient\apache-tomcat\bin\tomcat-juli.jar;c:\webclient\apache-tomcat\bin\bootstrap.jar
In my case i "installed" tomcat at: c:\webclient\apache-tomcat replace that part with yours. In my case not even the Java VM was set.. I'm not shure whether this is a problem with the current versions of tomcat (and it's service.bat), or with some sort of permission problem on the windows server itself..

To solve this error perform the following steps:
Run the tomcat7w.exe monitor application found in <TOMCAT_HOME>/bin.Tomcat7w is a GUI application for monitoring and configuring Tomcat services. If you named your service Mytomcat7 you will need to rename this file to Mytomcat7.exe before running it
In the "Startup" tab change the value of "Mode" from jvm to Java
Do the same in the "Shutdown" tab

The easiest way to setup a tomcat Windows service is to use the Tomcat Windows Service Installer found on the same page as tomcat downloads.
http://tomcat.apache.org/download-70.cgi
However, if you are unable to use this installer. Then you can as you have try the above. The service created 'Mytomcat7' can be managed by the tomcat7w.exe file, after you rename it to 'Mytomcat7w.exe'.
Run the renamed file and you will be able to see all options for the service. The error you are seeing is likely related to an invalid JVM location or JVM mode not set to auto.
Details of settings found here:
http://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html
I would just use the installer, it will make your life easier.
http://mirror.ox.ac.uk/sites/rsync.apache.org/tomcat/tomcat-7/v7.0.50/bin/apache-tomcat-7.0.50.exe

JAVA EE 7 First cup tutorial, can't install Glassfish 4 update center

Well I was trying to follow the first cup tutorial, but I'm stuck with a Glassfish error.
I'm supposed to this:
1.2.4 Getting the Latest Updates to the Tutorial
Check for any updates to this tutorial by using the Update Center
included with the Java EE 7 SDK.
1.2.4.1 Update the Tutorial Through the Update Center Open the Update Center and check for any updates to the tutorial.
In NetBeans IDE, select the Services tab and expand the Servers node.
Right-click the GlassFish Server instance and select View Update
Center to display the Update Tool. In the tree, select Available
Updates to display a list of updated packages. Look for updates to the
First Cup for Java EE 7 (javaee-firstcup-tutorial) package. If there
is an updated version of First Cup, select First Cup 7.0 for Java EE 7
(javaee-firstcup-tutorial) and click Install.
The thing is, when I try to open the Update Center, this is what I get:
The software needed for this command (updatetool) is not installed.
If you choose to install Update Tool, your system will be automatically
configured to periodically check for software updates. If you would like
to configure the tool to not check for updates, you can override the
default behavior via the tool's Preferences facility.
Exception in thread "main" java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:633)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:658)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)
at com.sun.pkg.client.Image.checkRepositoryConnection(Image.java:1225)
at com.sun.pkg.client.Catalog.refresh(Catalog.java:132)
at com.sun.pkg.client.Image.refreshCatalogs(Image.java:1627)
at com.sun.pkg.client.Client.main(Client.java:109)
When this tool interacts with package repositories, some system information
such as your system's IP address and operating system type and version
is sent to the repository server. For more information please see:
http://wikis.oracle.com/display/updatecenter/UsageMetricsUC2
Once installation is complete you may re-run this command.
Would you like to install Update Tool now (y/n):
C:\Program Files\glassfish-4.0>"C:\Program Files\Java\jdk1.7.0_40\bin\java" -Dimage.path="C:\Program Files\glassfish-4.0\bin\\.." -jar "C:\Program Files\glassfish-4.0\bin\\..\pkg/lib/pkg-client.jar" refresh
C:\Program Files\glassfish-4.0>"C:\Program Files\Java\jdk1.7.0_40\bin\java" -Dimage.path="C:\Program Files\glassfish-4.0\bin\\.." -jar "C:\Program Files\glassfish-4.0\bin\\..\pkg/lib/pkg-bootstrap.jar" "C:\Users\Fabio\AppData\Local\Temp\pkg-bootstrap11073.props"
Proxy: Using system proxy settings.
Input/output error: Connection reset
Could not download application packages. This could be because:
- a proxy server is needed to access the internet. Please ensure that
the system proxy server settings in your Internet Options control panel
(under Connections:LAN Settings) are correct, or set the HTTP_PROXY
environment variable to the full URL of the proxy server.
- the package server or network connection is slow.
If you are getting time out errors you can try setting the
PKG_CLIENT_CONNECT_TIMEOUT and PKG_CLIENT_READ_TIMEOUT
environment variables and try again. For example to increase
the timeouts to 300 seconds set them to 300
- the package server is down or otherwise inaccessible or it is
generating invalid data. Please contact the provider of the package
server.

This may be a problem with the slow GlassFish update server. Here are some steps you can try:
You should retry first to see if the error occurs again. You can start a cmd, navigate to the \glassfish\bin directory and run updatetool.bat so you can see the output which is printed after the one you posted.
If you are behind a proxy you should make sure it is setup correctly in the system settings.
You can also try to install the updates through the GlassFish admin console. Start your GlassFish instance and navigate to http:\\localhost:4848. On the bottom of the left menu click on Updatetool. There you can choose and install the desired updates.
Another option is to change the timeouts of the pkg tool. To set the timeout to 300 seconds do the following in a cmd (on Windows):
set PKG_CLIENT_CONNECT_TIMEOUT=300
set PKG_CLIENT_READ_TIMEOUT=300
Your last (ok, there may be other ones) option is to just skip the update process and do the tutorial with the current version. It should work anyway and I can see in my GlassFish update center that there is only an update for the tutorial documentation at the moment.

Just set this line into cmd (like administrator):
set PKG_CLIENT_CONNECT_TIMEOUT=300
set PKG_CLIENT_READ_TIMEOUT=300

Maybe the firstcup example is already existed in the install directory. Try to find it in the directory_install_glassfish/glassfish4/docs. The mine contain even javaee-tutorial and firstcup. For the next part, you maybe continue after guide in firstcup.pdf with the part of : Creating Your First Java by create archetype of java project. Good luck !

For the lazy of you the pkg Unix command is:
export PKG_CLIENT_CONNECT_TIMEOUT=300
export PKG_CLIENT_READ_TIMEOUT=300

After being stuck for a while on the installation of GlassFish update server from Netbeans (in my company network, proxy issues), I got it this way:
- Advanced System Settings > System Properties window > Advanced tab, New System Variable: http_proxy, http://username:password#your_proxy:your_port
- Netbeans (running as admin just in case), Services > Server > Glassfish Server > Right button View Domain Update Center, then install
It worked for me, Hope it helps!