This question already has answers here:
CronJob not running
(19 answers)
Closed last month.
I'm having problem with crontab when I'm running a script.
My sudo crontab -e looks like this:
05 00 * * * /opt/mcserver/backup.sh
10 00 * * * /opt/mcserver/suspend.sh
05 08 * * * /sbin/shutdown -r +1
11 11 * * * /opt/mcserver/start.sh <--- This isn't working
And the start.sh looks like this:
#!/bin/sh
screen java -d64 -Xincgc -Xmx2048M -jar craftbukkit.jar nogui
and have these permissions (ls -l output)
-rwxr-xr-x 1 eve eve 72 Nov 24 14:17 start.sh
I can run the command from the terminal, either using sudo or not
./start.sh
But it wont start with crontab.
If i do
grep -iR "start.sh" /var/log
I get the following output
/var/log/syslog:Nov 27 11:11:01 eve-desk CRON[5204]: (root) CMD (eve /opt/mcserver/start.sh)
grep: /var/log/btmp: Permission denied
grep: /var/log/lightdm/x-0-greeter.log: Permission denied
grep: /var/log/lightdm/lightdm.log: Permission denied
grep: /var/log/lightdm/x-0.log: Permission denied
So my question is, why isn't it working?
And since my script run without using sudo, I don't necessarily need to put it in sudo crontab?
( and I'm using Ubuntu 12.10 )
Thanks in advance,
Philip
Answer to twalberg's response
1. Changed owner on craftbukkit to root, to see if that fixed the problem.
-rw-r--r-- 1 root root 12084211 Nov 21 02:14 craftbukkit.jar
and also added an explicit cd in my start.sh script as such:
#!/bin/sh
cd /opt/mcserver/
screen java -d64 -Xincgc -Xmx2048M -jar craftbukkit.jar nogui
2. I'm not quite sure what you mean here. Should I use the following path in my start.sh file when i start java?
(output from which java)
/usr/bin/java
3. When my server closes, screen is terminated. Is it a good idea to start screen in "detached mode" anyway?
Still got the same "Permission denied" error.
Problem solved!
By using the proper flag on screen, as below, it is now working as it should!
screen -d -m java -d64 -Xincgc -Xmx2048M -jar craftbukkit.jar nogui
Thanks a lot to those who answered, and especially twalberg!
Here are some things to check:
root obviously has read/execute permissions on start.sh, but what are the permissions on craftbukkit.jar - can root read it? You may also want to add an explicit cd /path/to/where/craftbukkit.jar/is in your start.sh script.
Is java in root's default path within cron? Note that this path is not necessarily the same as the one that you get via sudo, su or directly logging in as root - it's typically much more restricted. Use full path names to both java and craftbukkit.jar to work around that.
Since screen will not start with a terminal available, you may need screen -d -m ... instead. Hopefully, you intend to eventually attach to each screen instance and terminate it later, or you have arranged for it to terminate automatically when the script is done...
The /var/log/syslog entry shows that cron did in fact execute the script, so it must have failed for one of the above reasons (or something else I haven't noticed yet)
The other errors from grep are simply due to the fact your non-root user does not have permission to read those specific files (this is normal, and a good thing).
start.sh is owned by "eve:eve" and your crontab is running as root.
You can solve this by running following command
chown root:root /opt/craftbukkit/start.sh
Your crontab will be running as root though.
Tip: When running bash in crontab always use absolute paths (it will make debugging a lot easier).
The log shows the user has no access to dir " /var/log/", You should set the log files' permition for the cron's owner.
Related
I am trying to run a root cronjob for executing a script.
Here's the cronjob I put into sudo crontab -e:
*/1 * * * * ~/temperature_log/logtemp.sh >> ~/temperature_log/templog.log>&1
The script requires root permission for hddtemp.
Unfortunately, the templog.log file never appears. The syslog says:
Jun 6 13:09:01 user CRON[32433]: (root) CMD (~/temperature_log/logtemp.sh >> ~/temperature_log/templog.log>&1)
Jun 6 13:09:01 user CRON[32426]: (CRON) info (No MTA installed, discarding output)
So apparently, the script IS run, but something goes wrong from there.
Even stranger: If I run a user cron via just crontab -e, the script executes (without root permissions, though, so it is of no use for me) and does write the log file.
How can I make sure that my root crontab works correctly?
I am connecting to this computer via ssh as a user without root permissions, but I do have the root passwort.
EDIT
I changed the program now, I want it to log to syslog via logger. Again, running the script manually works and it logs correctly, but running it from crontab just shows this:
Jun 6 14:27:01 user CRON[1657]: (root) CMD (Jun 6 15:06:01 insystems CRON[25328]: (root) CMD (/bin/sh ~/temperature_log/logtemp.sh)
No information is logged. I added the /dev/null part to get rid of the email warning. I am not planning on installing an email service.
Have you written the script to send email alerts? The warning, "(No MTA installed, discarding output)", happens when a mail service is not installed.
Most Linux distributions have a mail service (including an MTA) installed. Ubuntu doesn't though.
You can install a mail service, postfix for example, to solve this problem.
sudo apt-get install postfix
Also, try providing the full path for the files (The absolute path):
~/temperature_log/logtemp.sh and ~/temperature_log/templog.log
Make sure logtemp.sh has execute permission. If no, then issue command
chmod +x logtemp.sh
My solution was to add the cronjob not to crontab -e but to /etc/crontab. From there, it worked without issues.
I probably made a mistake in the other crontab file, but this solution is okay for me.
I'm using CentOS 7, and installed "cronie"
yum install cronie
I have a shell to backup my home folder, shell's content (of course, backup.sh is 775)
#!/bin/bash
#START
TIME=`date +%Y-%m-%d_%Hh%M`
FILENAME=backupHome_123.30.150.29_$TIME.tar.gz
SRCDIR=/home
DESDIR=/backup
tar -cpvzf $DESDIR/$FILENAME $SRCDIR
#END
And add to crontab -e
00 2 * * * /bin/bash /backup/backup.sh
But crontab does nothing. When I check log at /var/log/cron only, something like that and no more error or processing log
May 1 00:26:08 app crontab[12041]: (root) END EDIT (root)
May 1 00:33:21 app crontab[12086]: (root) BEGIN EDIT (root)
May 1 00:34:25 app crontab[12086]: (root) END EDIT (root)
Anyone can give me some advises to make crontab work?
Thank you.
I found that the most useful information was actually given by
systemctl status crond
Which revealed that it failed to load correctly due to an "Unauthorized SELinux context" error.
This can happen if cron daemon isn't running.
Check it with:
pgrep cron
If command returns nothing, run:
systemctl restart crond
This should help.
You want to make sure cron is started & that it is started if your server reboots so you need two commands on CentOS 7 to make sure of this:
systemctl enable crond && systemctl restart crond
If you are used to using sudo, you can add sudo in front of above command. like this:
sudo systemctl enable crond && systemctl restart crond
YOU WILL get confirmation from system, something like:
Created symlink from /etc/systemd/system/multi-user.target.wants/crond.service to /usr/lib/systemd/system/crond.service.
Then lastly check cron is running
pgrep cron
I know that I'm late to answer you, but maybe someone will have this kind of problem. It is possible that CRON can't run the script because the path is not correct.
Your path is
00 2 * * * /bin/bash /backup/backup.sh
I guess that path should be:
00 2 * * * sh /bin/bash/backup/backup.sh
Only difference is space after bash directory and sh command at the start of CRON job.
You have to add username before your command like this for example :
1 * * * * root or username /usr/bin/php /var/www/html/yourwebsite/yourscript.php
I have a VPS with Nagios installed, and I want to use Nagios to monitor the VPS resources in the /proc/user_beancounters file. The file has the following permissions:
-r-------- 1 root root 0 Oct 26 15:53 /proc/user_beancounters
So I downloaded the script from the Nagios Exchange:
https://exchange.nagios.org/directory/Plugins/Operating-Systems/*-Virtual-Environments/OpenVZ/check-beancounters/details
In the instructions it suggests to:
don’t forget to set the s-bit (chmod +s check_UBC.pl)
So, I copied the script over, and set the s-bit, then run it from the terminal as root. It works as expected. I then delete the temp file it created, su into the nagios user, and run the script. It works as expected. I delete the temp file it created, and start up Nagios. It can't read the /proc/user_beancounters file! The exact error I get, helpfully, is "could not read /proc/user_beancounters". This is, I believe, thrown by the line in the Perl script:
if (! open IN, "<", $UBC )
{
print "could not read $UBC\n";
exit $ERRORS{'CRITICAL'};
}
My OS is CentOS release 6.2 (Final).
My first thought is that it is some kind of SELinux voodoo, but there is no indication that SELinux is running on this server. Just in case, I tried the following:
echo 0 > /selinux/enforce
But this made no difference.
For reference, this is my nagios service running:
nagios 12939 0.0 0.0 203652 3404 ? Ssl 15:39 0:00 /usr/sbin/nagios -d /etc/nagios/nagios.cfg
And this is where I've put the Perl script:
-rwsr-sr-x 1 nagios nagios 2934 Oct 26 15:37 check_UBC.pl
Any suggestions as to what else I can try?
PS apologies if this should go in a different SE site - never sure with questions that involve scripts, permissions etc...
UPDATE 1
I created a shell script to see if I could 'emulate' the nagios service. It is extremely simple:
#!/bin/bash
/usr/lib64/nagios/plugins/check_UBC.pl
And now I have the following permissions:
-rwsr-sr-x 1 root root 2934 Oct 26 15:37 check_UBC.pl
-rwxrwxrwx 1 root root 51 Oct 26 19:29 check_UBC.sh
As root:
[root#/usr/lib64/nagios/plugins]$ ./check_UBC.pl
everything is fine..
[root#/usr/lib64/nagios/plugins]$ ./check_UBC.sh
everything is fine..
As nagios:
-bash-4.1$ ./check_UBC.pl
everything is fine..
-bash-4.1$ ./check_UBC.sh
everything is fine..
So still no clue...
UPDATE 2
My nagios command definition:
define command{
command_name check_beancounters
command_line $USER1$/check_UBC.pl
}
And the service definition:
define service{
use local-service
host_name localhost
service_description VPS Beancounters
check_command check_beancounters
}
UPDATE 3
I managed to get it to work, but am not over the moon about giving the nagios user full sudo access with no password. In /etc/sudoers I put this on the last line:
nagios ALL=(ALL:ALL) NOPASSWD: ALL
And then changed my command definition to:
define command{
command_name check_beancounters
command_line sudo $USER1$/check_UBC.pl
}
Apparently recent versions of linux will not respect the +s permission when running an interpreted script, only a binary. So I guess I will have to compile a binary wrapper for the script?
UPDATE 4
As per Joe Young's suggestion, I changed my visudo entry to:
nagios ALL=NOPASSWD: /usr/lib64/nagios/plugins/check_UBC.pl
Which hopefully is relatively harmless!
Try changing the owner of check_UBC.pl to root so that when nagios executes check_UBC.pl the script runs as setuid of it's owner root and not the nagios user.
chown root:root check_UBC.pl
EDIT:
Can you post your command definition that's calling check_UBC.pl?
The last thing I can think of to try is to install the perl-suid module: https://chrisjean.com/fix-setuid-cannot-exec-sperl/
Although, if check_UBC.pl runs from the command line with no problem, I'm not sure what difference it would make.
What would the risk be to change the permissions on /proc/user_beancounters to 444 (read for all?) It only contains a number, correct? Not sure if that particular file "sticks around" after a reboot, or worse, constantly gets replaced as the services are running, so this could be a problem still.
Also, consider trying to test for actual "existence" of the file, before you attempt to read from it. Since we're in /proc directory, things do change, from time to time....
Lastly, you are asking to open the file, but syntactically is it asking to open in a read only mode? You may want to try a system call to simply "cat" the file contents, in your shell script, and see if you get a response.
I am new to linux and the script below is just an example of my issue:
I have a script which works as expected when I execute it however when I set it to run via crontab it doesn't work as expected because it doesn't read the file content into the variable.
I have a file 'test.txt' which has 'abc' in it. My script puts the text into a variable 'var' and then I echo it out to a log file:
var=$(</home/pi/MyScripts/test.txt)
echo "$var" >/home/pi/MyScripts/log.log
This works perfectly fine when I execute it and it echo's into the log file but not when I set it via crontab:
* * * * * /home/pi/MyScripts/test.sh
The cron job runs, and it sent me the following error message:
/bin/sh: 1: /home/pi/MyScripts/test.sh: Permission denied.
But I have given it 777 permissions:
-rwxrwxrwx 1 pi pi 25 Jun 10 15:31 test.txt
-rwxrwxrwx 1 pi pi 77 Jun 10 15:34 test.sh
Any ideas?
This happens when you run the script with a different shell. It's especially relevant for systems where /bin/sh is dash:
$ cat myscript
echo "$(< file)"
$ bash myscript
hello world
$ sh myscript
$
To fix it, add #!/bin/bash as the first line in your script.
Others have provided answers, but I will give you a big clue from your error message; emphasis mine:
/bin/sh: 1: /home/pi/MyScripts/test.sh: Permission denied.
Note how the cron job was trying to use /bin/sh to run the script. That’s solved by always indicating which shell you want to use at the top of your script like this.
#!/bin/bash
var=$(</home/pi/MyScripts/test.txt)
echo "$var" >/home/pi/MyScripts/log.log
If your script is using bash, then you must explicitly set /bin/bash in some way.
Also, regarding permissions you say this:
But I have given it 777 permissions:
First, 777 permissions is a massive security risk. If you do that it means that anyone or anything on the system can read, write & execute the file. Don’t do that. In the case of a cron job the only entity that needs 7 permissions on a file is the owner of the crontab running that file.
Meaning if this is your crontab, just change the permissions to 755 which allows others to read & execute but not write. Or maybe better yet change it to 700 so only you—as the owner of the file—can do anything to the file. But avoid 777 permissions if you want to keep your system safe, stable & sane.
You have two options. In the first line of your file, tell what program you want to interpret the script
#!/bin/bash
...more code...
Or in your crontab, tell what program you want to interpret the script
* * * * * bash /home/pi/MyScripts/test.sh
In this option, you do not need to make the script executable
I'm using a basic shell script to log the results of top, netstat, ps and free every minute.
This is the script:
/scripts/logtop:
TERM=vt100
export TERM
time=$(date)
min=${time:14:2}
top -b -n 1 > /var/log/systemCheckLogs/$min
netstat -an >> /var/log/systemCheckLogs/$min
ps aux >> /var/log/systemCheckLogs/$min
free >> /var/log/systemCheckLogs/$min
echo "Message Content: $min" | mail -s "Ran System Check script" email#domain.com
exit 0
When I run this script directly it works fine. It creates the files and puts them in /var/log/systemCheckLogs/ and then sends me an email.
I can't, however, get it to work when trying to get cron to do it every minute.
I tried putting it in /var/spool/cron/root like so:
* * * * * /scripts/logtop > /dev/null 2>&1
and it never executes
I also tried putting it in /var/spool/cron/myservername and also like so:
* * * * * /scripts/logtop > /dev/null 2>&1
it'll run every minute, but nothing gets created in systemCheckLogs.
Is there a reason it works when I run it but not when cron runs it?
Also, here's what the permissions look like:
-rwxrwxrwx 1 root root 326 Jul 21 01:53 logtop
drwxr-xr-x 2 root root 4096 Jul 21 01:51 systemCheckLogs
Normally crontabs are kept in "/var/spool/cron/crontabs/". Also, normally, you update it with the crontab command as this HUPs crond after you're done and it'll make sure the file gets in the correct place.
Are you using the crontab command to create the cron entry? crontab to import a file directly. crontab -e to edit the current crontab with $EDITOR.
All jobs run by cron need the interpreter listed at the top, so cron knows how to run them.
I can't tell if you just omitted that line or if it is not in your script.
For example,
#!/bin/bash
echo "Test cron jon"
When running from /var/spool/cron/root, it may be failing because cron is not configured to run for root. On linux, root cron jobs are typically run from /etc/crontab rather than from /var/spool/cron.
When running from /var/spool/cron/myservername, you probably have a permissions problem. Don't redirect the error to /dev/null -- capture them and examine.
Something else to be aware of, cron doesn't initialize the full run environment, which can sometimes mean you can run it just fine from a fully logged-in shell, but it doesn't behave the same from cron.
In the case of above, you don't have a "#!/bin/shell" up top in your script. If root is configured to use something like a regular bourne shell or cshell, the syntax you use to populate your variables will not work. This would explain why it would run, but not populate your files. So if you need it to be ksh, "#!/bin/ksh". It's generally best not to trust the environment to keep these things sane. If you need your profile run the do a ". ~/.profile" up front as well. Or a quick and dirty way to get your relatively full env is to do it from su as such "* * * * * su - root -c "/path/to/script" > /dev/null 2>&1
Just some things I've picked up over the years. You're definitely expecting a ksh based on your syntax, so you might want to be sure it's using it.
Thanks for the tips... used a little bit of each answer to get to the bottom of this.
I did have the interpreter at the top (wasn't shown here), but may have been wrong.
Am using #!/bin/bash now and that works.
Also had to tinker with the permissions of the directory the log files are being dumped in to get things working.