I have a script say:
[operations#dojo 2018-02-23--18-10-53 ~ $] ls -l cc_snapshot.sh
-rwxr-xr-x 1 operations users 6006 Feb 23 15:02 cc_snapshot.sh
/etc/cron.allow
operations
crontab -l
*/3 * * * * operations /home/operations/cc_snapshot.sh arg1 arg2 >> /var/log/cc_snapshot.log
However nothing gets printed in the /var/log/cc_snapshot.log.
If I remove the operations user from the cron I do see errors in /var/log/cc_snapshot.log as the script is not supposed to be executed as root user.
Any advise as to what I might be wrong here?
Clearly a file permission issue. root is the supper user in Unix environment and it can execute any script in that system. Hence second error message is coming from your script but not from shell. You script don't want it to be run by root. Check the user account whether it has proper access to the file location and proper permission to execute the script. These are the very common issues in Unix environment. Also check whether your user id is added to proper group or not.
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 have a problem with crontab, it does not execute my shell sript.
Crontab -l :
01 * * * * login sh ~/delete.sh
Normally every minute it should execute delete.sh, but it doesn't.
Nothing in syslog:
Jul 8 14:00:31 crontab[22307]: (login) LIST (login)
Jul 8 14:01:08 crontab[22581]: (login) BEGIN EDIT (login)
Jul 8 14:01:51 crontab[22581]: (login) REPLACE (login)
Jul 8 14:01:51 crontab[22581]: (login) END EDIT (login)
Jul 8 14:02:01 cron[15185]: (login) RELOAD (crontabs/login)
--> THAT'S ALL.
PS: I've tried running it as root and as the normal user, no luck in either case.
You're expecting this:
01 * * * * login sh ~/delete.sh
to run the command every minute. In fact, it only runs it at one minute past each hour.
Change it to this:
* * * * * login sh ~/delete.sh
To address issues raised in the comments:
Cron jobs run with a limited $PATH, but /bin is certain to be in that $PATH, so there's no need to replace sh by /bin/sh.
There's no need to invoke sh explicitly. Just make sure that ~/delete.sh has a proper shebang (#!/bin/sh or #!/bin/bash) and that it's executable (chmod +x ~/delete.sh), and you can invoke it directly.
I don't know why you have a login command. It doesn't make sense to try to log in from a cron job. In any case, login doesn't take a command as an argument.
If login is meant to be a user name rather than a command, keep in mind that there are two different syntaxes for crontab entries. In the normal syntax, each line consists of 5 fields specifying when the job runs, followed by the command and its arguments. A system crontab entry adds a user account name between the time specification and the command. man 5 crontab for details. In normal usage, you should use the normal user syntax and manage your crontab using the crontab command; don't edit /etc/crontab or files under /etc/cron.* unless you absolutely have to.
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 have the following "root-file" with the following contents:
$ cat root-file
#!/bin/bash
echo $EUID
id
Following are the permissions for this file:
$ ls -l root-file
-rwsr-sr-x 1 root root 15 Nov 18 02:20 root-file
Since the set-user-id bit is set for this file, I would expect that on executing this
file, the effective uid would be displayed as 0 even when a non-root user executes it (since set-user-id bit causes the process to be executed with the effective user-id of the owner of the file, which in this case is root). However, instead I get the following output on executing "root-file" from a non-root shell.
$ ./root-file
1000
uid=1000(chanakya) gid=1000(chanakya) groups=1000(chanakya),4(adm),20(dialout),24(cdrom),46(plugdev),105(lpadmin),119(admin),122(sambashare)
This file/or script is not being executed with effective user-id 0. Why is that so?
you cannot use setuid on shell scripts...
if you absolutely need to use setuid checkout http://isptools.sourceforge.net/suid-wrap.html
Normally something like this could also be established using some custom sudo configuration...
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.