I have a cron task configured in cron.d directory that would get executed for every 5 minutes. The entry is
*/5 * * * * root /usr/sbin/logrotate /etc/logrotate.d/test_consolelog
This would invoke the logrotate. However the logrotate didn't happen. I checked the /var/log/cron file to see if cron executes the command and could see that the command is getting executed for every 5 minutes.
I tried executing the command mannually on the terminal and could see that the command is executed and log rotation happens.
What could be reason that logrotate is not happening when getting executed from cron.d.
Regars,
Bala
I found the root cause. The SELinux needs to be disabled for this to work. Earlier while testing the sestatus value is disabled in the the /etc/selinux/config file however the current status was enforcing. Once i restarted the vm itself the sestatus updated to disabled and logrotate functioned as desired. prior to that i have fixed the bad minute error too.
I had furnished enough details for this post and done enough research before posting here. However i am not sure why some one marked this post as there is no research effort or unclear or unuseful...
Related
I have been stuck on this for a while and this is new territory for me so I need some help. I am working on a project where a cron service is created when a user is created with a web application. However, I am running into problems actually getting the cron service to run. Here is what I have tried
1) Creating a cron service using
crontab -l | { cat; echo "'comand'"; } | crontab -
This creates the job fine. However, it creates it with www-data as the user and those do not show to execute.
I should mention that I am setting path to
PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
as I am running a python script that I have made executable using chmod +x and put the appropriate headers to make sure it runs properly (which it does). In addition, all paths are full paths. To be more clear, here is the actual command I am using inside the crontab
*/10 * * * * /home/user/path-to script/script.py --user_id 1 --db_file /home/user/path-to-file/file.db
However, the script never runs.
2) Creating a file under /etc/cron.d, but from my testing, I have realized that this only works if the file is created as a root user, which since the user creating the file is www-data, the job will again, not execute.
for reference, I am doing that as such:
*/10 * * * * user /home/user/path-to script/script.py --user_id 1 --db_file /home/user/path-to-file/file.db
What does work is repeating steps 2 & 3 using a user that is part of the sudo group or is the root user. This tells me that I need to create the cron job using one of those two users, but I am not sure how to do that programmatically when www-data is being used for web activities.
Another option I have considered is using crontab -u user to programmatically add the job to a user I know works, but the issue with that is that in order to do that I need sudo access and I don't want to pass in the sudo password when creating the cronjob or do something that might be potentially dangerous (like removing the need to use sudo as I know that is possible, but in my opinion could be very bad is someone gains access to the account and therefore has escalated privileges)
Help would really be appreciated.
As for the stack, if it's helpful, I am using Ubuntu 18.04.3 (LTS) x64 and Apacahe2
I have 1and1 web hosting. I am supposed to be able to set up cron jobs using crontab to execute on the server. I have a job set up as follows (including showing the full path to my PHP installation):
(uiserver):u*******:~ > which php5.4
/usr/local/bin/php5.4
(uiserver):u*******:~ > crontab -l
20 * * * * /usr/local/bin/php5.4 /kunden/homepages/40/d*******/htdocs/job.php
If I execute the command manually in the terminal, it runs fine. But the cron job never runs.
Am I missing something obvious?
I've tried checking the cron logs, but I just get permission denied, unfortunately, so that was no help for troubleshooting. The joys of being on somebody else's server, I guess...
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 run a cron job at 5:20pm as below but it's not working.
20 17 * * 1 /usr/bin/php /home/myacc/public_html/job/generate.php
I basically did crontab -e and entered the above line there and saved the file.
If I try running the command directly from the command line as below, it works fine:
php /home/myacc/public_html/job/generate.php
What am I doing wrong?
Also, how do I send a message from the cron to either a log file or email so that I know what's going on?
You can record all the logs of your cronjobs by installing postfix and configuring it as local domain during installation. Such that you can see the logs of your cron jobs by vi /var/mail/<user-name>. Try looking the logs and figure out the problem. If you don't find any solution post the log so that it will help others to diagnose the problem. I'm adding this as an answer instead of comment because i think I'm answering your second query.
I had a cronjob set up to run a php script daily, which went well for about a month. Today, I realized it didn't run the script so I opened up the crontab. The crontab is completely empty - what happened?
I don't know too much about cronjobs, but as far as I understand, they do not delete themselves if the server is reset. How can I make sure cronjobs are always running and that it doesnt get deleted?
It is probably under a different user. Check root user sudo crontab -e. Each user has it's own crontab and there's one for the whole system. Note: Through the crontab configuration you can disable per-user crontabs.