Cron Job Mysteriously Stopped Running

Cron job mysteriously stopped running?

There should be something in your system log when the job was run. The other thing you could >try is to add 2>&1 to the job to see any errors in your text file. – Lars Kotthoff yesterday

This proved to be the key piece of information - adding 2>&1 allowed me to capture an error that wasn't getting reported anywhere else. The completed command line then looked like:

java -jar /home/mydir/myjar.jar  2>&1  >>/home/mydir/crontaboutput.txt

Cron Jobs stopped working

Well, I wound up contacting my hosting support. Turns out the domain was moved to a new server and the cron jobs were still running on the old one.

New to Cron Jobs - and Cron Job not running?

Cron jobs are nothing mysterious. All a cron job is, is a time interval and a shell command. At every time interval, the shell command will be run.

The cron job you have supplied here consists of these two parts:

• (* * * * *) denotes the time interval. This is five fields separated by a space. The fields denote, in order: minute, hour, day, month, and weekday. If you specified a number in one of the fields, such as 1 in the minute field, it would only run the cron job when the current minute was 1. A 10 in the hour field would only run when the current hour was 10. A * means that any value is fine. Five stars means to run the command once every minute of every hour or every day of every month. Curiously, if you had * 10 * * * it would run the cron job every minute of the 10th hour of every day of every month.

• wget --quiet /wp-admin/admin-ajax.php?action=THE_PLUGINS_FUNCTION is the shell command to run. This is just a shell command. You can test the shell command outby running it in a shell.

The problem you have is that your arguments to wget are not correct. The --quiet argument to wget means that it will not produce much output. The /wp-admin/admin-ajax.php?action=THE_PLUGINS_FUNCTION is the address to request. wget is failing because /wp-admin/admin-ajax.php?action=THE_PLUGINS_FUNCTION is not a valid address - the schema (http:) and hostname (test.domain.com) are missing.

You can fix your cron job by changing it to:

(* * * * *) wget --quiet http://test.domain.com/wp-admin/admin-ajax.php?action=THE_PLUGINS_FUNCTION

You will need to add a new cron job for every subdomain you want to run this command on.

You can check to make sure you have your wget command working correctly by pasting it in a shell and running it. Once you know it is working fine, add it as a cron job and it should work just fine.

Why is my azure pipeline cron job not running?

All seems fine to be with your pipeline. I tested it with this code:

trigger: none
pr: none
schedules:
- cron: "0 0 * * *"
  displayName: Daily midnight build when changes have been pushed
  always: true
  branches:
    include:
    - branch1
    - branch2
    - master
variables:
- group: BranchVariables

steps:
- script: echo "hello $(test)"

Please keep in mind that you have filter for specific branches, so make sure that branch1 or branch2 exists.

I created a new branch branch1 and changed to default branch for the pipeline and ten synced schedules:

Cron doesn't run Rails Puma server automatically in Ubuntu

Depending on your version of Puma, the --daemon option might be deprecated. Use & instead:

bundle exec puma -C /srv/www/apps/app/shared/puma.rb &

However, your issue isn't with Cron or with Puma. Puma doesn't exit on its own unless something else happens. I recommend that you have a look at the error logs and figure out the real issue.

Edit:

To answer your comment:

1. I recommend that you update Puma to version the latest 4.x release (currently 4.3.6). If you can switch to Puma 5.x (currently 5.1) that would be even better. There are bug fixes and improvements all the time. Maybe your issue is related to a solved bug.

2. If you update to the 5.x version family, you will need to replace the --daemon with a & as mentioned above.

Side Note:

However, I still believe there's an error report you didn't notice of that your toolset failed to log.

I don't know if you looked at the Capistrano logs as well as the Rails / Puma logs and the DigitalOcean server logs.

If you're running Puma with --debug, some Puma messages must appear in the log.

How to find the error which is causing a segmentation fault in a script run by cron job

Try this

0 20 * * * /usr/bin/wget --timeout=10800 \
-O /home/File.txt http://www.site.com/script.php  >> /home/log.txt 2>&1 

the 2>&1 part tells to send the STDERR to the same place as STDOUT.

---

Related Topics