I'm doing server migration in sun solaris OS. And I have to migrate crontabs also with that. New server have fresh installation of solaris. In usual way while I type crontab -l it shows the existing cron content.
But while I type crontab -e it fail to load the editor. How can I overcome this issue?
This can be fixed by exporting editor variable with value vi. So run following command and then run crontab -e
export EDITOR=vi
crontab -e
Related
I use an Amazon Lightsail Lamp Server.
I am trying to edit a CRON job, which I setup previously using crontab -e but the editor keeps returning 964 and a blank page.
crontab -l shows the content of the file.
Any tips ?
Solved. The issue was with the text editor used by my terminal.
These were the steps I took :
export EDITOR=/bin/nano
source ~/.bashrc
echo $EDITOR
export VISUAL="/bin/nano"
All we know that cron ignores variables defined in “.bashrc” and “.bash_profile”, so we have to define it inside cron. I constantly do the same what was written inside the similar question https://unix.stackexchange.com/questions/67940/cron-ignores-variables-defined-in-bashrc-and-bash-profile but still global variables inside .bashrc still not working. I found way to execute it - by defining sh script with "set +a" bashrc script. But "source" still doesn't work.
SHELL=/bin/bash
BASH_ENV=/root/.bashrc
PATH=:/opt/spark/spark-2.2.0-bin-hadoop2.7/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SPARK_HOME=/opt/spark/spark-2.2.0-bin-hadoop2.7
MAILTO=root HOME=/
# m h dom mon dow command
* * * * * /bin/bash -c 'source $HOME/.bashrc; echo "SPARK_HOME: '$SPARK_HOME'"; echo "JAVA_HOME: '$JAVA_HOME'"' > /var/log/file.log 2>&1
# DO NOT DELETE LAST LINE
return log file
SPARK_HOME: /opt/spark/spark-2.2.0-bin-hadoop2.7
JAVA_HOME:
also tried to execute this in interactive mode as it was written by mklement0
source .bashrc in a script not working
* * * * * /bin/bash -i source /root/.bashrc; echo $JAVA_HOME > /var/log/file.log 2>&1
As you can see SPARK_HOME is defined inside crontab whilst JAVA_HOME only in .bashrc. P.S in bashrc java home is defined "export JAVA_HOME=/usr/jdk1.8.0_131"
All different cron jobs work fine when I change JAVA_HOME to SPARK_HOME, tried different crontab jobs but the answer is the same as it was.
ubuntu kernel version is
uname -a
Linux 6101c32b9243 4.9.62-21.56.amzn1.x86_64 #1 SMP Thu Nov 16 05:37:08 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Your last attempt runs bash and sources the file, then exits Bash and runs the echo in the calling shell, which isn't Bash, and of course doesn't know or care that the now-defunct Bash process loaded some settings and then forgot them when it exited. (Or, well, this is what would happen if you fixed the simple quoting errors to keep the source command and its argument as a single string.)
The superficial fix is easy;
* * * * * bash -c 'source $HOME/.bashrc; echo "$JAVA_HOME"' >/var/log/file.log 2>&1
The proper fix, however, is probably to encapsulate all of this in a separate script and keep your crontab really simple.
(Are you really sure your user is allowed to overwrite the log file? Replacing the log once a minute seems rather misdirected, although it's good enough for a quick test to see if the job is running at all.)
I want to edit system cron tab (/etc/crontab). I read that crontab -e is the best way to edit crontab and you need not restart cron services if you edit this way. However I am not able to edit /etc/crontab using crontab -e (this command edits the crontab associated with the user, not system crontab). So is there any better way of editing /etc/crontab (other than using VI editor- which I am doing now). Do I need to restart cron services if I edit /etc/crontab using VI edior?
There are two ways of cronjobs, one is by editing /etc/crontab and sending a SIGHUP the cron daemon. The other way is to use crontab -e to edit
a crontab entry, which is done for the current user or the one mentioned with -u. The -u option can only be used by root. The crontabs
created this way can be found in the directory
/var/spool/cron/crontabs/
and are named after the user with which uid the jobs will be started. In this case you don't need to SIGHUP cron, a normal user can't do this anyway.
Note: The syntax is slightly different to /etc/crontab: You can't enter an other user name to execute the cronjob.
You could do something like this
echo "0 23 * * * yum -y update > /dev/null 2>&1" >> /var/spool/cron/root
Then verify with
crontab -l
I noticed that when I typed sudo crontab -e I dont see my cron command, but when I do only crontab -e there is my command.
Is there a difference between the 2? If there is, where should I put my cron command, should it be in sudo or without the sudo?
Thanks!
Is there a difference between the 2?
Yes, indeed they are different.
The difference is that with sudo crontab -e the commands are schedule with root user's credentials. So that the commands in the sudo's cron table are executed as root user.
But with crontab -e, the commands are scheduled with the regular user who is logged in.
Where should I put my cron command, should it be in sudo or without the sudo?
Well, the answer to this depends on the type of command you want to run.
If the command required sudo access then sudo crontab -e should be used.
Else if the cron command doesn't require any special permission then use crontab -e.
Example:
If the ethernet network interface eth0 should be disabled or enabled at specific time then you would use the command
ifconfig eth0 up or ifconfig eth0 down
As the above commands require special permission (sudo), these commands are supposed to added to sudo's cron tab
Any other command which require minimal permission or no permission like removing a file from tmp directory like $ rm /tmp/somefile use the regular user's crontab.
Main part of the problem is to take care of the user with whom you wanna make your things done. Otherwise it will not trigger your cron job. And do make sure that you write output of your command in any file. It will help you to debug the problem which most probably might relate to your relative paths.
That's what I faced difficulties in. You can move forward following the below step:
identify your username with which you wanna go. Use whoami command.
Turn to your selected user mode and type crontab -e.
And append line < cron-schedule your-command >> output_filename.cron 2>&1 >
That's it.
Thanks!
I'm trying to make cron jobs or task schduler working, but I can not figure out why my script is not taken in consideration.
I'm trying to simply archive a folder with:
tar -cvf /volume1/NetBackup/Backups/Monday.tgz /volume1/NetBackup/Backups/ns3268116.ovh.net/
Each time the script starts working but cannot achieve the work. Either with task scheduler or crontab, a file Monday.tgz is created in folder /volume1/NetBackup/Backups/, but this file is only 1024 bytes.
Synology Cron is really fussy.
Here are my own personal notes for Synology DS413j, DSM 5.2:
Hand edit /etc/crontab as root, crontab -e isn't available
Ensure you use tabs not spaces to separate the columns
Your crontab changes may not survive a reboot if there are syntax problems
The who column in crontab may not be reliable. Use root in the who column and /bin/su -c '<command>' <username> to run as another other user
remember that it uses ash not bash so check for bashisms, e.g use >> /path/to/logfile 2>&1' not&>> /path/to/logfile`
It doesn't support 'MAILTO='
you need to restart crond synoservicectl --reload crond for the new crontab to take effect
You may try adding some diagnostics to it. For instance:
Add MAILTO into the crontab file (on top of crontab -e) to receive cron errors by email:
MAILTO=username#domain.com
Redirect output of your tar command to the file:
your command > ~/log.txt 2>&1
Check cron log and look for anomalies. For instance (it may depend on your configuration):
/var/log/cron.log
You may also try searching through /var/log/messages at the time of your cron job.
Is volume1 a resource on remote host? If yes, it is worth checking this part of the system.
I agree about the really nagging nature of Crontab on Synology Linux OSs.
I would certainly suggest to create de desired job as a .sh shell script and call it via CRON task inserted by using the GUI, as suggested here.
As for today (March 2017) is the best method I have found, since working with crontab via CLI is nearly a pain.