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.
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?
I've been using forever for a long time but recently it started to behave a little bit weird: everything is ok except for the logs.
I used to run forever start /path/to/app.js and everything was fine. Even for huge logs (1-2 gigs).
But I currently have an app, a very busy web app and the log is being truncated every 3-4 hours. The size is not that big, 80-120 megs actually.
After realising this I decided to try (unsuccessfully though) starting forever with options: forever --append -o /path/to/out.log -e /path/to/error.log start /path/to/app.js but the problem persists.
I really don't know what to do.
Any thoughts??
Thanks!!
Versions:
node v0.12.7
npm 2.11.3
forever v0.15.1
3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 GNU/Linux
UPDATE1:
BTW: I have plenty of hard disk an memory available
UPDATE2:
I found a related Issue (https://github.com/foreverjs/forever/issues/106#issuecomment-116933382) and beging testing with the following command: forever -a -l >(logger -t fileteTrackchile) start /path/to/app.js So far so good, but it will store log information in /var/log/user.log, /var/log/syslog and /var/log/messages. It's the same information so it would be better to save it only once.
I'll leave it running for a couple of days and see if it works or not.
UPDATE3 (FINAL):
The problem had nothing to do with forever, nor winston. I didn't realise that the files were so big that the log viewer was only showing part of it. The confusing part is that the first line (past) was truncated by the viewer (OSX Console) what led me to think that the file itself was truncated.
Regarding your first approach, unexpected log truncation is often caused by log rotation. However, you didn't mention rotating your logs.
Your second approach is to send the logs to a syslog daemon using the logger client.
Your logging is then ending up in three logs due your syslog configuration.
Try this solution. Create a file named /etc/rsyslog.d/10-fileteTrackchile.conf.
In the file, add these lines:
$template JustMsg,"%msg:2:10000%\n"
if $programname == 'fileteTrackchile' then /var/log/fileteTrackchile.log;JustMsg
if $programname == 'fileteTrackchile' then stop
Then:
service rsyslog stop
service rsyslog start
Because the file name starts with 10, it will get run before other configuration.
The logic instructs the logging for your app be logged to a particular file, unmodified, and then stop further processing by rsyslog, so the logging doesn't end up in the three other files you mentioned.
You may also wish to create /etc/logrotate.d/fileteTrackchile with contents like this:
/var/log/fileteTrackchile.log
{
rotate 7
daily
missingok
notifempty
compress
sharedscripts
postrotate
service rsyslog reload >/dev/null 2>&1 || true
endscript
}
See man logrotate for the details of those log rotation options.
The problem had nothing to do with forever, nor winston. I didn't realise that the files were so big that the log viewer was only showing part of it. The confusing part is that the first line (past) was truncated by the viewer (OSX Console) what led me to think that the file itself was truncated.
I don't know if this was an effect of the shellshock attack which my server was victim to (or another attack that worked) but it basically enabled the hacker to overwrite my SSH config file when the server rebooted.
This new file used wget to load in a file from a website, then another library of hack functions which I guessed he then used to run hacks/DOS from my server. I caught it pretty fast and ideally want to upgrade but because I have cancer and just had a big operation it is too much effort at the moment.
Therefore I did a lot of house keeping, changing passwords, removing shell access, reverting back to DASH, replacing the default shell for root and any other users to another folder with symbolic links, restoring the config file for SSH, removing CGI functionality from config files e.g
ScriptAlias /cgi-bin/ /home/searchmysite/cgi-bin/
#
allow from all
#
Removed AW stats and Webalizer for all virtual min sites.
I already had DenyHosts and Fail2Ban installed.
I also blocked in/outbound traffic to the IPs of the sites he was getting the files from.
However it seems since this change I have lost the visual cron manager from webmin.
When I go to the menu item "Scheduled Cron Jobs", it says, "The command crontab for managing user Cron configurations was not found. Maybe Cron is not installed on this system?"
However I can see in the file system it exists.
When I run crontab -l or crontab -e I get "Permission Denied"
whoami shows "root"
I did think at the time of the hack this was all related and he had used SSH and a Cron job to get his hack running.
What I want to know is how I can get the CronTab manager back.
All the cron jobs are still running such as importing feeds into my websites, running scheduled emails and so on, what I don't know is how to resolve this without a full rebuild.
If I had the time and energy I would do that but I am totally drained and before this hack everything was just running smoothly and my websites which bring me in money were working fine.
They currently are still working fine and I regularly check my logs for IPs that look odd, have strong htacess rules for xss/sql/path travesal/file hacks and ban whole countries from Cloudflare which the site sits behind. So I don't "think" the machine is compromised at the moment even if it is old - could be wrong though!
details of box
Operating system Debian Linux 5.0 Virtualmin version 3.98.gpl GPL WebMin Version: 1.610 Kernel and CPU Linux 2.6.32.9-rscloud on x86_64
So if anyone can help me get my crontab manager back that would be great.
Thanks
1) check if chattr exists, if not, download a new one.
2) type whereis crontab, then chattr -isa /path/to/crontab.(usually /usr/bin/cron) then chmod crontab back to it original settings.
3) navigate to /var/spool/ and
chattr -isa cron
cd cron
chattr -isa crontabs
4) remove cron entry in /etc/cron.weekly
Look in /etc/cron.weekly for any new
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
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!