Tag Info

Hot answers tagged

7

You have to use Ctrl+x to exit nano and install new crontab. Ctrl+z will just stop/send to background nano without installing new crontab. See attached screenshot:


5

Which distribution are you using? According to Ubuntu's run-parts manual: If neither the --lsbsysinit option nor the --regex option is given then the names must consist entirely of ASCII upper- and lower-case letters, ASCII digits, ASCII underscores, and ASCII minus-hyphens. Therefore run-parts won't run a script named test.bash. Thanks to this ...


4

This is handled by anacron, which runs the default cron.daily etc. jobs on Fedora. If this is a root job, you can either add it to the /etc/cron.daily or to /etc/anacrontab.


4

1) Why do we need the curly brackets Because you need to pipe both the output of cat and the output of echo to crontab -. Without the curly braces you can't assemble the output of the two commands in a single pipe. (or can we use single quotes) here Nope. ... | 'cat; echo "0 0 * * * /path/to/cron/job"' | ... means "pipe to an executable named ...


4

This IBM support article explains how stepping works. In the case of */5, it would occur every 5 minutes (0, 5, 10, etc). That is the same as 0-59/5. In the case of 0/5, I just tested it and it will never run.


4

The answer from SF is accurate as far as it goes, though if all the lines you wish to comment are in one block there is a way "around" this problem. It's not standard practice, and the end result is individual comment markers on every line. My editor of choice for crontab files is vi, so other editors may or may not have similar functionality, but if you ...


3

I think on debian cron writes logs in /var/log/syslog. If your system depends on rsyslogor syslogd you can check and uncomment either in /etc/rsyslog.conf or /etc/syslog.conf for line: # cron.* /var/log/cron.log and then restart services. If your system depends on systemd for example you can check with following command: journalctl _COMM=cron or ...


3

The most reliable way to test whether a crontab line is valid is to ask the crontab utility. Most crontab utilities don't have an option to only validate and not change the crontab. You can call crontab -e to set the crontab, and if this succeeds restore the previous content, but this is not robust: if the input is valid, a job that it contains could be ...


2

The shutdown command has already an embedded scheduler so you don't need a cron job for it to run at the specified time. In Linux as everywhere else, it's better to stick to the KISS principle (Keep It Short and Simple). shutdown -h 22:00 will work fine, no need to run it in the background. Add the command at the end of /etc/rc.local (or ...


2

For some reason /usr/bin/vi is not working correctly on your machine as you can tell from the error message: crontab: "/usr/bin/vi" exited with status 1 What happened there is that when you leave vi it is producing an error code. When crontab sees that vi exited with an error code, it will not trust the contents of the file vi was editing and simply ...


2

The immediate issue is that your file (script.sh) needs to be in the files directory under the module, i.e. /etc/puppet/modules/homebackup/files/script.sh. Confusingly, the files part of the path is not part of the source URI. You also have another error: The File requirement AFAIK needs to refer to the name of the file resource, that is, it should be ...


2

The user server does not have any schedule job in crontab so crontab -l outputs that information, not an error. Normally, you can find a user's crontab file in directory /var/spool/cron/crontabs.


2

That's probably because this user does not have a crontab, yet. You can create a crontab for this user by calling: crontab -e


1

I'm assuming by parent folder you just mean the folder with filename.txt. You can get find to print this folder name with -printf '%h\n' instead of the -exec. You can pipe this into a shell loop or xargs for example: find /path/ -name "filename.txt" -type f -mtime -2 -printf '%h\n' | xargs -i rsync ... {} /destination \; I think you need to add -R to ...


1

use nohup scriptForB.sh inside scriptForA.sh... in that way, the child process will not be terminated when the parent process exits.. On termination, parent process will send SIGTERM signal to all child process. If you use nohup, the child process will ignore the SIGTERM signals.


1

You need to use full paths to the output files and probably to the executables as well. When run in cron, there is no pre-existing environment for it to know things like a working directory or a path.


1

You can wrap your python daemon in a shell script. When you first initiate, check if the process is already running: pid=$(cat pid.file) ps -ef | grep $pid | grep <command to start daemon> if [[ $? -eq 0 ]]; then echo "daemon already running" & exit 1 else <command to start daemon> & \ echo $! > pid.file fi


1

cron will not give you a list of events. What it can do is start your script on a regular basis. Have the script do the following: read a date-time-stamp from a configuration file into var X increment X with a pre determined event interval (e.g. 60 minutes) while X < current date-time execute the rest of the script and write X to the configuration file ...


1

You can just start the example.py with the full path to example-env/bin/python2. Alternatively change the shebang line of the example.py to use that executable, make that file executable (chmod +x example.py) and leave out python and use the full path to example.py to start it: #!/full/path/to/example-env/bin/python2


1

I won't give an answer to the original question here, but if you're trying to schedule tasks for Mac OS 10.9+ with cron, you're doing it wrong: crontab is deprecated. You should use launchctl with launchd (man page here) instead. launchd/launchctl works with .plist files that describe each task, similar to the way you'd use systemd/systemctl with .service ...


1

Depending on your system, user crontabs are saved in /var/spool/cron/. Check you have this directory. Also the crontab program is setuid so you cannot read other people's crontabs, so check this (-rws...): $ ls -l /bin/crontab -rwsr-xr-x 1 root root 57536 Sep 18 2014 /bin/crontab Your vim seems to exit with an error code. Try putting your entry in a file ...


1

Your unit test script probably calls tput in order to generate pretty output showing which tests pass and fail. Under cron there is no terminal and thus no terminal type ($TERM), so tput cannot control the nonexistent terminal. Your unit test script needs to have 2 modes: running on a terminal: it can call tput to generate pretty-looking output not ...


1

Damn, just after I posted my question I figured out the problem (after trying to find an answer for about an hour or two). It would seem that tarsnapper just outputs all of its normal output to stderr instead of stdout. I think this is a bug in tarsnapper. But to answer my own question I just need to redirect using 2>/dev/null instead (to rediredt ...


1

You can simulate the cron user environment as explained in "Running a cron job manually and immediately". This will allow you to test the job works when it would be run as the cron user.


1

You can also put your commands into a shell file and then execute the shell file with cron. jobs.sh echo hello >> ~/cron-logs/hourly/test`date "+%d"`.log cron 0 * * * * sh jobs.sh



Only top voted, non community-wiki answers of a minimum length are eligible