Tag Info

New answers tagged

0

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.


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:


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


0

I ended up just running the commands in a single crontab line with && and inside of a bash -l -c statement, it is working now!


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 ...


0

The historic default to report output from cron jobs is to post the logs through the system mailer (/usr/sbin/sendmail by default).


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 ...


-4

vi /var/spool/cron/*user* or if you're the root user then vi /var/spool/cron/root


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 ...


0

The output of a cron job doesn't go to your screen. It can't — you might not even be logged in by the time the job runs! The output of a cron job is sent via email. A working unix system always has a local email facility, which is independent of a network connection. If you want your local email to be sent to a remote account, create a .forward file in your ...


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


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 ...


0

Apparently it is not an out of the box task. I found a library in python: https://pypi.python.org/pypi/python-crontab that allow to find a "schedule" for a single job: schedule = job.schedule(date_from=datetime.now()) ... datetime = schedule.get_next() That is exactly the needing. Looping from date_from last reboot date while datetime less than now.


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 ...


0

Why don't you write the status to non-volatile storage i.e. /var/tmp/status_task_x and read the last set status from that same file on the next run? In that case it should survive a reboot. In a crontab example: * * * * * status_task_x=$(<"/var/tmp/status_task_x") /path/to/run_task_x $status_task_x Have the task script write the output to ...


0

This is a HUGE security risk, but wget www.website.com cronjob.txt crontab -u username cronjob.txt But your crontab looks wrong. Why do you need to sudo, cron jobs run as the user they are installed for. So you would be better to just put the lines in asterisk's crontab. sudo crontab -u asterisk then add 0 3 * * * ...


0

wget -O - www.website.com/cronjob.gz|zcat|sudo tee -a /etc/crontab or crontab -l | cat - <(wget -O - www.website.com/cronjob.gz|zcat)| crontab - The disadvantage of these commands is that they do not check to verify that the commands do not exist. You are better off using crontab.d or cron.d directories if they exist and creating a file in them with ...


0

*/X means every X minute of the hour. Depending on the minute you set, it runs every minute or not. For example */5, every 5 minutes. */35 every 35th minute of the hour. If hours were 70 minutes long, */35 would run every 70 minutes. I hope this answer is not traumatizing Gilles.


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.


0

Sounds like cron was started before the time synchronization had settled, so the fix is to sync the time before cron starts.


0

You should add the following to your gnu tar command: --warning=no-file-changed That will suppress all the "%s: file changed as we read it" messages. And by using this solution (and not redirecting everything to /dev/null), you will still be able to get error messages when stuff really goes wrong.. With the --warning flag you can enable and disable a lot ...


0

You specified bash in the shell script and then attempt to call your script with sh in the crontab. There is really no need to specify the shell in crontab since you specify it in the shebang, so this should work just fine: * * * * * /home/pi/checker.sh


0

I usually just crontab -u user file in someting like /etc/rc.local and have that load a cron tab. Other then that, there is not a lot to do. I would normally do something like: (in rc.local) wget http://169.254.169.254/latest/meta-data/instance-id -O /tmp/instance INSTANCE=`cat /tmp/instance` KEY="/etc/pk.pem" CERT="/etc/cert.pem" ...


0

Use a fully qualified path in crontab ie. /bin/sh /home/pi/checker.sh


0

The post rotate action appears to be incorrect Try invoke-rc.d nginx reload >/dev/null 2>&1 If you look at the nginix command you will see the actions it will accept. Also the message you got says check initctl --help xtian@fujiu1404:~/tmp$ initctl help Job commands: start Start job. stop Stop ...


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 ...


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 ...


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 ...


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 ...


0

Here is something I sometimes add on a server to easily handle race conditions for any job's on the machine. It is simmilar to Tim Kennedy's post, but this way you get race handling by only adding one row to each bash script that needs it. Put the content below in e.g /opt/racechecker/racechecker : ZPROGRAMNAME=$(readlink -f $0) EZPROGRAMNAME=`echo ...


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 ...


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 ...


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 ...


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 ...


0

What you want is a daemon, not a cron job. A cron job is for executing something periodically (or at boot), not for keeping a process alive. I encourage you to read that article, then do something very simple like this: #!/bin/sh while true do /my/script.php >> /var/log/my_script.log 2>&1 done


1

When you run the crontab -e command, it lets you edit a temporary file. When you exit the editor, the temporary file is checked for syntax errors, and if there aren't any, it's installed in the system directory that contains users' crontabs. If you save the file to a different location, then the temporary file will not be modified, and thus your previous ...


4

They are completely different things. systemd is an init system (replaces the old systemV init). It extends it in the following ways: It unifies the init, login and initscripts, so that different distributions no longer have each its own custom set of scripts to load daemons It tracks the services (daemons) so that it has control over them after they ...


-2

To run cron task every 30 minutes, cron expression will be like this: */30 * * * * /path-to-file/filename



Top 50 recent answers are included