Adding log4j [1] in tomcat 6.0.x forces tomcat to produce logs in "catalina" file. However, the default catalina.out is still produced and populated with logs. So, questions:
Is it safe to delete catalina.out file (while server running)?
If yes, could this deletion be added to tomcat startup script? If yes, could anyone please point out the file and the required script?
Is it possible for tomcat to stop createing the catalina.out, since it is not nessesary anymore?
http://tomcat.apache.org/tomcat-6.0-doc/logging.html
Thanks in advance people!
Tomcat redirects its stdout and stderr to catalina.out. So direct out/err writes and log4j ConsoleAppender messages will go to catalina.out. See catalina.sh file for details. To disable it completely you can redirect stdout and stderr to /dev/null setting CATALINA_OUT environment variable:
export CATALINA_OUT=/dev/null
But I recommend to disable ConsoleAppender instead to reduce catalina.out size and monitor it periodically looking for error messages, that may go to stdout bypassing log4j.
If the catalina.out is deleted after tomcat is stopped, it will create a new catalina.out once tomcat starts again and it is totally safe.
But if you remove the catalina.out while tomcat is running, it will keep on logging to catalina.out which is removed already (reference of the file is hold by the tomcat) hence the space will not be released. So you will need to restart the tomcat sever to release the space. It is not recommended.
You can try following to disable writing to catalina.out :
Locate and Edit File: {CATALINA_BASE}/bin/catalina.sh
Locate "CATALINA_OUT" and replace the path with "/dev/null":
CATALINA_OUT="$CATALINA_BASE"/logs/catalina.out // Original Location
CATALINA_OUT=/dev/null // replace path to /dev/null
Is there a reason you'd want to delete the catalina.out file? It seems like it might lead to potentially missing important event messages. Perhaps consider just setting
org.apache.catalina.level=INFO
Otherwise I can't think of a reason that it would negatively impact the functionality of the container if you deleted it. On a *nix install its still writing to the file descriptor of a file that is diconnected from an inode(so otherwise unreachable) and on windows it won't let you delete it because the container will have a file lock.
logging docs - a quick rtfm and it looks like you should just be able to remove the handlers from logging.properties to discontinue producing this file
Related
I removed a custom logrotate configuration within the /etc/logrotate.d/ directory since it was no longer needed, and it appears it is still trying to process that previous configuration becuase I am getting emails from the servers stating the following:
error: cannot stat /etc/logrotate.d/process: No such file or directory
The man pages for logrotate do not mentioned the process for deleting the configurations, just how to create them. Since there is no logrotate daemon to restart, would anyone know why its still trying to execute the previous non-existing configuration?
My computer runs serveral java processes as systemd services.The systemd logs get accumulated in the syslog eventually leading to low disk space . How to re-direct the logs started by systemd services towards /dev/null so that it does not accumulate in syslog.The machine is constantly running out of disk space due to this issue.However , I need to be able to use journalctl to view the systemd service logs. The possible solutions I found were :
1.To modify configurations in /etc/systemd/journald.conf by setting
'ForwardToSyslog=no'
2.Adding StandardOutput=null within the systemd service file itself
However the first solution completely stopped all the logs sent to syslog and solution 2 did not work.I wish to stop forwarding only the log messages from systemd services.
The second option with StandardOutput=null should work. I think what you need is to redirect also STDERR to /dev/null, by adding StandardError=null.
Summarize - in your *.service file should be two lines:
[Service]
StandardOutput=null
StandardError=null
Refer SYSTEMD.EXEC(5) man page for more details.
Similarly on a Redhat 7.4 box, running systemd-219-42.el7_4.1.x86_64, I was unable to turn off log redirection with the ForwardToSyslog=no setting in /etc/systemd/journald.conf.
I instead had success with setting MaxLevelSyslog=warning which removed all the INFO and DEBUG level messages that were being forwarded to rsyslog.
You can configure rsyslog to ignore logs from specific application:
# cat /etc/rsyslog.d/mydaemon.conf
if $programname == 'mydaemon' then {
stop
}
This will result in:
You will see systemd-generated messages about daemon being started/stopped/reloaded/etc within journal AND syslog.
You will see daemon's-generated messages ONLY in journal (and custom log file written directly by application, if any).
Alternatively, you can use the journalctl command to limit the size of the journal. You can limit the size of the journal to a certain size, by adding the following line to /etc/systemd/journald.conf:
SystemMaxUse=10M
This will limit your journal to 10 MB.
You can still use "syslog" to redirect logs from the service to /dev/null. In your system file try:
[service]
SyslogIdentifier=<service-name>
StandardOutput=null
SyslogFacility=local7
Meanwhile, check that the syslog deamon is configured to receive logs with local7 facility. In rsyslog configuration file make sure that:
local7.* /dev/null
journalctl should still be working.
check out the systemd manual for more information
If your service is logging to a file, the messages will not be appended to systemd syslog.
For example:
[Service]
StandardOutput=append:/var/log/python-script-stdout.log
StandardError=append:/var/log/python-script-stderr.log
will forward all messages (stdout and stderr) only to their respective filepath.
If you want to truncate the logs on every service startup, replace append: with file:.
I've accidentally copied over my default.vcl and erased my fairly complex configuration. So long as I don't try to reload the configuration or restart Varnish everything is running fine - I'm hoping there's a way to view or "extract" my loaded configuration from Varnish so I don't have to rewrite it from scratch. Thanks for any ideas.
You may as well login in the admin console ( varnishadm) and run vcl.list to list all the vcl that are loaded. And then vcl.show to display the most recent one.
Vcl list is cleared when varnish service is restarted or stopped.
Solved my issue by recovering my loaded config file using -
grep -i -a -B100 -A100 'text' /dev/vda
Replaced 'text' with a line of code I remembered from the config.
I am trying to roll the log catalina.out on a webserver using logrotate.
I have been able to roll the log and a log catalina.out-dateext is created.
But I notice that the log is being written in the new file catalina.out-dateext.
Is there something that need to be done on the webserver?
Thank you
Add copytruncate in your /etc/pex/tomcat file. For more info about all the options: vineetmanohar.com/2010/03/howto-rotate-tomcat-catalina-out
I have installed successfully the roar-penguin pppoe-server and trying to use it without success, what I don't understand is that, when I put in my /etc/ppp/pppoe-server-options
debug
logfile /var/log/pppoe-server-log
But that file is not created and I don't understand what happens. It is really hard for me find a solution. Do you know how can I enable the debugging ?
My problem is that I catch every time (Wireshark sniffing) the
RP-PPPoE: Child pppd process terminated
In the PADT message, any help ?
Thanks in advance.
From your question not being formatted, verify that debug and logfile in /var/log/pppoe-server-log are on separate lines in your configuration file. Also, ensure that you've restarted the service to utilize the new configuration. If the service is not running as root, be sure that the user it runs as has ownership over the logfile to write to it. If it is running as root, ensure the file exists and that it's writable.
If it doesn't exist, just run:
# touch /var/log/pppoe-server-log
# chmod 0774 /var/log/pppoe-server-log
I would think this should be done automatically, but you may as well do so just to ensure it's created properly and you can verify ownership/permissions as needed.