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?
Related
My VPS Server (CPanel) got full so I decided to delete some files, namely the following
ssh root#server_ip_address
MB(space) File Location
2583 /home/someuser/tmp/analog/cache <-------------1
1883 /home/someuser/tmp/analog/cache.out <-------------2
1061 /usr/tmpDSK <------------3
When I deleted the first two files it did free up some 4GB of space the disk was showing 85% occupied. Then I deleted the tmpDSK file (1.06GB) but it had no impact on disk size. After some half, an hour or so, our server crashed and it won't serve pages. It is up though and I can ping it but pages are not served.
What I noticed right away after I deleted tmpDSK, the user/local/ folder was missing (got deleted by mistake?) which contains Apache, Perl etc and hence the reason web sites are not being served.
Just now I logged in to the server via SSH and I got the following messages
-bash: /usr/local/cpanel/3rdparty/bin/perl: No such file or directory
-bash: /usr/local/cpanel/3rdparty/bin/perl: No such file or directory
-bash: /usr/local/cpanel/3rdparty/bin/perl: No such file or directory
I am wondering, what possibly happened. Can I restore things myself, we do have a backup on the external drive? Is there a way deleted files can be restored? I deleted them from sftp, one by one. There is already a ticket opened with the host provider, but I want to understand things myself better and see if I can restore it somehow. Note none of the Linux commands works on SSH, like ls etc. Also tmpDSK is supposed to be cPanel related where it store sessions, temporary files
Thanks
Answering myself
After more than 24 hours of troubleshooting with the host, and then personally researching we found the issue was very trivial.
We accidentally moved the contents of /usr/local/ folder to /usr/include which cause all the problems. Simply moving it back fixed the problem.
The content was moved unexpectedly when working with server with FTP (sftp). It likely had nothing to do with the three deleted files that I had deleted.
I have a dedicated server running Linux/Apache with cPanel. On one of my website's users are able to register and upload images.
However, over the last few days, i have received complaints that users cannot upload any media. When I check the /images/ directory I see that the /temp/ folder is missing.
So I re-created it and set the permissions to 0777.
Once that is completed all works fine. But I cannot understand why the directory is being removed. No one else has access to the site and I do not see anything in my error logs that show anything unusual.
Any ideas why this may happen?
Thank you
You need to check your PHP Script has code to unlink(dir) or Something
and Check cron list whether you have added any CRON to remove the TMP folder.
for Write permission 755 is enough If you are using Fcgi php handler, cgi, dso. Have a try 755 permission with one of the listed Handlers.
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.
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