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
Related
I did configuration inside logrotate.d for tomcat catalina.out and fixed the size to 200M below are my config file:
/opt/apache-tomcat-7.0.55/logs/catalina.out {
copytruncate
size 200M
rotate 20
compress
missingok
daily
}
but unfortunately it does not run even the log cross 900 MiB. I have to manually run the command logrotate -f tomcat. The manual execution works so I believe my configuration is right.
DO I need to reboot the box or anything need to be done to get this file executed.
I even tried by removing daily from the file but nothing changed.
This is first time I am configuring the logrotate.
Sounds like its not setup to run in the cron. http://www.cyberciti.biz/faq/how-do-i-add-jobs-to-cron-under-linux-or-unix-oses/ provides a good overview
Sorry to say I'm not sure what else it could be other than possibly file permission issues.
I have an Rsyslog central server where multiple machine send log files and these log files are stored by machine IP.
$template DailyPerHostLogs,"/var/log/remote/%fromhost-ip%_%$YEAR%-%$MONTH%-%$DAY%.log"
*.* -?DailyPerHostLogs
This works fine however all the logs gets into the logmachines central logs as well like:
/var/log/messages
/var/log/auth
/var/log/cron
What is the best way to stop this from happening?
Thanks
Solved it, have to put the remote log acception rule first then this:
## before going to local log rules, drop remote logging, it's been
## processed in the "central logging" section
#
:hostname, !isequal, "biglogserver" ~
Then rest of the rsyslog.conf
If I understood your question right, you won't save the logs locally on the machines.
To do that you must remove from /etc/syslog.conf all the lines that describe local log files, and leave there only the line that send the logs remotely.
so I have a basic out of the box wordpress installation setup on my instance of a ec2 AMI server. I want to set up wordpress logging. I checked that logging is set to true in my wp-config.php file, and I am expecting a standard debug.log file to show up in wp-content. However this is not happening. Are the errors being piped somewhere else? Could it be that that I am missing some small configuration detail (that usually is the case.) I'm not sure what is wrong. Thank you for your time and help.
Edit: so now I can see that the PHP error log is in the logs folder, accessible from the root directory by default. However, what is still confusing is that I want to be able to route my wordpress errors to the logs that exist, or perhaps just set up my own debug.log file in the existing log directory. I'm reviewing wordpress logging and PHP ini stuff, but I cannot generate a log file. Any help would be greatly appreciated.
I use this plugin in all Wordpress developments. You simply create a file called php-error.log in the root of your Wordpress install, set a few lines in wp-config (instructions after activating plugin in dashboard), and your log will also automatically appear in the dashboard.
http://wordpress.org/plugins/error-log-monitor/
For some tests I'm doing, I'm required to remotely tail the apache access log via ssh. I can successfully do that only when the permissions are accurately set for the log. I've noticed that once a week, a new apache access.log is created and the permissions are reset.
My current work around is editing the permissions on the log once a week:
chmod 644 /var/log/apache2/access.log
I was wondering if there was a more permanent solution such as extending the time that the old log remains or automatically setting permissions when the new log is created.
If it matters, I'm running the server on Ubuntu 11.10
Edit your logrotate.conf file to set the correct owner/permissions for the apache.log file. Something like this:
/var/log/apache2/access.log {
weekly
create 0644 root utmp
rotate 1
}
(Edit: Changed mode from 0744 to 0644. No need to set the execute bit.)
Maybe another application, like logrotate, is altering the logs? (Sounds like it, as it only happens weekly) I don't think Apache itself is responsible for the permissions chance.
A good place to start is check /etc/cron./* to see if any cron jobs are touching the access.log
Good luck!
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