On Ubuntu 20.04 I have a SpringBoot web app.
The logging directory, I send in via the "setenv.sh" file in the CATALINA_BASE/bin folder as recommended by Apache (in their catalina.sh file).
So, /usr/share/tomcat9/bin/setenv.sh has this single statement:
CATALINA_OPTS="${CATALINA_OPTS} -DLOG_DIR=/var/lib/tomcat9/logs"
Then, I set both CATALINA_HOME and CATALINA_BASE point to /usr/share/tomcat9 in ~/.bashrc.
In SpringBoot, application.properties has this line:
logging.file.name= ${LOG_DIR}/ws.log
Now, when the webapp starts, the "ws.log" file does get created. That's OK so far.
But no logging statements ever get written to it. It's always zero bytes.
The permissions for that log file look like this (in /var/lib/tomcat9/logs):
-rw-r----- 1 tomcat adm 0 Jan 19 15:53 ws.log
I would greatly appreciate some guidance where I've gone wrong. There is no log message in the other log files in Tomcat indicating that there is any problem with the log file setup.
Thanks very much in advance,
Related
My standalone.xml resides in the repo for inclusion in the docker image. As I have no working docker on my local Windows 7 machine, I'm using a local Wildfly 14 (14.0.1.Final). I tried starting Wildfly with the jboss.server.config.dir property pointing to this standalone, but then Wildfly complains about not finding logging.properties in the same directory, so I must have my standalone.xml in the Wildfly config directory.
To avoid having a possibly outdated copy of standalone.xml in wildfly-14.0.1.Final\standalone\configuration, I created a symlink:
>mklink standalone-myapp.xml c:\path\to\standalone.xml
>dir standalone-myapp.xml
...
07.11.2018 10:24 <SYMLINK> standalone-myapp.xml [c:\path\to\standalone.xml]
However when Wildfly starts, it overwrites the symlinked file and it's not any longer a symlink:
>dir standalone-myapp.xml
...
07.11.2018 10:28 23'069 standalone-myapp.xml
Can this behaviour somehow be configured or fixed?
Update
In fact using the read-only mode (--read-only-server-config) allows to specify a standalone.xml in a directory without logging.properties. If I had know this option I wouldn't have experimented with a symlink.
I still think it's a bug that Wildfly doesn't update the file pointed at by the symlink, but it doesn't bother me anymore...
You could pull your standalone configuration from git ;) or start WildFly in read-only mode thus avoiding this overwriting (but loosing any changes you might be doing on the configuration).
When I start my spring boot app as a systemd service I receive this error:
start-stop-daemon: warning: this system is not able to track process names longer than 15 characters, please use --exec instead of --name.
Spring boot seems to build the process name from the jar name and the directory the jar is contained in. Is there any way to fix this aside from renaming the jar, and the directory it's contained in, to be shorter than 15 characters?
If I try to edit spring boots startup script to use --exec instead of --name then I get another error:
'start-stop-daemon: unable to stat /opt/program/programname_optprogramname (No such file or directory)
It appears that this issue is fixed in Spring boot 2.0.2. So if you run into this issue upgrading might fix it (not to imply that upgrading is always a simple effort)
I am using Hibernate Search in my webapp. I wanted to deploy application to Ubuntu Server with Tomcat. Yet it throws same error independent of index location place set in configuration file.
At beginning I set to directory in home folder like this:
<property name="hibernate.search.default.indexBase">/home/someuser/indexes</property>
Permissions of this folder were like following:
drwxr-xr-x 2 tomcat7 tomcat7 4096 Jun 30 14:44 indexes
Then I tried to relative path and created folder indexes in webapps with same permissions:
<property name="hibernate.search.default.indexBase">indexes</property>
In both case throws the same error:
Caused by: org.hibernate.search.exception.SearchException:
Cannot write into index directory: .
I don't understand why it tries the current folder.
With regards
Hibernate Search will write by default in the current directory: ".".
You are setting the correct property; the only explanation I have is that you are not setting it in the right configuration file.
Hibernate also reads JVM properties and environment variables when it doesn't find a property before resorting to the default.
I wouldn't normally recommend to set such options on the JVM command line, but it might be interesting to try this out in your case.
You can also add additional properties in a hibernate.properties resource file.
I'm using https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html to start my spring-boot application on ubuntu 14.04 and it's working great except my log file gets overwritten whenever I restart the app. Probably it's something simple... but how can I configure that behaviour? I'm just using the default console logging to /var/log/app_name.log. If I pass in the logback "--logging.file=..." config to the init script, it logs both to the default as well as this file and this file doesn't get overwritten. Thanks!
I see these in the my Linux folder hierarchy after installing the Zend Framework.
/oradiag_root/
/user/myuser/oradiag_myuser/
/user/myuser/oradiag_root/
This name reminds me of Oracle. But I did not find any official documentation about this.
I didn't install any Oracle server. What's going on here?
I never installed Oracle on my system and don't know why these directories kept being created, but I finally managed to stop them from reappearing. Here's how it's done.
First, head over to:
cd ~/oradiag_<username>/diag/clients/user_<username>/host_*/trace/
and then
head sqlnet.log
You should see an error message complaining about a directory not existing for r/w. For me, it was /usr/lib/log. I created the directory it was complaining about and deleted the oradiag_<username> directory, only to have it reappear later; however, the sqlnet.log file was now complaining about a different directory.
I repeated this process of creating directories a few times until the directory finally stopped appearing. In your case, the directories may be different, but here's what solved it for me:
sudo mkdir /usr/lib/log/diag/clients
sudo chmod 777 /usr/lib/log/diag/clients
Only the clients directory needs to be 777, apparently.
Now just wipe out the oradiag_<username> directories wherever they currently appear. They shouldn't pop up for you again.
In case you're curious, here's what finally ended up being written to that "missing" directory:
mike#mike-ubuntu:/usr/lib/log/diag/clients$ ll -a
total 8
drwxrwxrwx 2 root root 4096 2011-08-24 10:34 .
drwxr-xr-x 3 root root 4096 2011-08-24 10:34 ..
Brilliant.
There are a lot of suggestions out there, but the only one that worked for me was this.
In Oracle 11gR1 and higher, you have to add this to your sqlnet.ora file first:
DIAG_ADR_ENABLED=OFF
After that, then other log-disabling settings should work:
TRACE_LEVEL_CLIENT = OFF
TRACE_DIRECTORY_CLIENT=/dev/null
LOG_DIRECTORY_CLIENT = /dev/null
LOG_FILE_CLIENT = /dev/null
LOG_LEVEL_CLIENT = OFF
The logs that are created are for the Oracle client. The logs may show up when any program tries to access an Oracle database.
These folder are created by the Oracle 11 SQL*Net if sqlnet.ora is not available or does not define the parameter ADR_BASE (see http://download.oracle.com/docs/cd/B28359_01/network.111/b28317/sqlnet.htm#BIIDEAFI).
If you've installed the Zend Framework, it appears to create these directories.