Skip to main content
added 178 characters in body
Source Link
Seamus
  • 5.1k
  • 3
  • 23
  • 44

This works on my Ventura system, and it should work on your Monterey system...

I don't think cron has a "log file" per se, and so I'll suggest you get into the habit of creating and using a file to capture the output of stdout and stderr from all cron jobs. It's the best way to troubleshoot mysterious cron issues.

FROM:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2

TO:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2 >> /Users/me/Desktop/test_log 2>&1

The information in the file test_log should contain something useful, and suggest where the issue is. I suspect - in this case - it's something simple.

Here's the breakdown on the addition:

  • >> a redirect (with augmentation instead of replacement)

  • 2>&1 redirect stderr to stdout; effectively combines both streams into a single stream

Another good habit with crontab entries that name an executable file is to specify the full path to that executable. You'll get away with it when the executable is in the PATH, but it may not be obvious what cron's PATH actually is.

Yet another good habit with cron is to turn OFF the default MAILTO feature. This is done by adding this line at or near the top of your crontab:

MAILTO=""

This works on my Ventura system, and it should work on your Monterey system...

I don't think cron has a "log file" per se, and so I'll suggest you get into the habit of creating and using a file to capture the output of stdout and stderr from all cron jobs. It's the best way to troubleshoot mysterious cron issues.

FROM:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2

TO:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2 >> /Users/me/Desktop/test_log 2>&1

The information in the file test_log should contain something useful, and suggest where the issue is. I suspect - in this case - it's something simple.

Here's the breakdown on the addition:

  • >> a redirect (with augmentation instead of replacement)

  • 2>&1 redirect stderr to stdout; effectively combines both streams into a single stream

Another good habit with crontab entries that name an executable file is to specify the full path to that executable. You'll get away with it when the executable is in the PATH, but it may not be obvious what cron's PATH actually is.

This works on my Ventura system, and it should work on your Monterey system...

I don't think cron has a "log file" per se, and so I'll suggest you get into the habit of creating and using a file to capture the output of stdout and stderr from all cron jobs. It's the best way to troubleshoot mysterious cron issues.

FROM:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2

TO:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2 >> /Users/me/Desktop/test_log 2>&1

The information in the file test_log should contain something useful, and suggest where the issue is. I suspect - in this case - it's something simple.

Here's the breakdown on the addition:

  • >> a redirect (with augmentation instead of replacement)

  • 2>&1 redirect stderr to stdout; effectively combines both streams into a single stream

Another good habit with crontab entries that name an executable file is to specify the full path to that executable. You'll get away with it when the executable is in the PATH, but it may not be obvious what cron's PATH actually is.

Yet another good habit with cron is to turn OFF the default MAILTO feature. This is done by adding this line at or near the top of your crontab:

MAILTO=""
added 243 characters in body
Source Link
Seamus
  • 5.1k
  • 3
  • 23
  • 44

This works on my Ventura system, and it should work on your Monterey system...

I don't think cron has a "log file" per se, and so I'll suggest you get into the habit of creating and using a file to capture the output of stdout and stderr from all cron jobs. It's the best way to troubleshoot mysterious cron issues.

FROM:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2

TO:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2 >> /Users/me/Desktop/test_log 2>&1

The information in the file test_log should contain something useful, and suggest where the issue is. I suspect - in this case - it's something simple.

Here's the breakdown on the addition:

  • >> a redirect (with augmentation instead of replacement)

  • 2>&1 redirect stderr to stdout; effectively combines both streams into a single stream

Another good habit with crontab entries that name an executable file is to specify the full path to that executable. You'll get away with it when the executable is in the PATH, but it may not be obvious what cron's PATH actually is.

This works on my Ventura system, and it should work on your Monterey system...

I don't think cron has a "log file" per se, and so I'll suggest you get into the habit of creating and using a file to capture the output of stdout and stderr from all cron jobs. It's the best way to troubleshoot mysterious cron issues.

FROM:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2

TO:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2 >> /Users/me/Desktop/test_log 2>&1

The information in the file test_log should contain something useful, and suggest where the issue is. I suspect - in this case - it's something simple.

Here's the breakdown on the addition:

  • >> a redirect (with augmentation instead of replacement)

  • 2>&1 redirect stderr to stdout; effectively combines both streams into a single stream

This works on my Ventura system, and it should work on your Monterey system...

I don't think cron has a "log file" per se, and so I'll suggest you get into the habit of creating and using a file to capture the output of stdout and stderr from all cron jobs. It's the best way to troubleshoot mysterious cron issues.

FROM:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2

TO:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2 >> /Users/me/Desktop/test_log 2>&1

The information in the file test_log should contain something useful, and suggest where the issue is. I suspect - in this case - it's something simple.

Here's the breakdown on the addition:

  • >> a redirect (with augmentation instead of replacement)

  • 2>&1 redirect stderr to stdout; effectively combines both streams into a single stream

Another good habit with crontab entries that name an executable file is to specify the full path to that executable. You'll get away with it when the executable is in the PATH, but it may not be obvious what cron's PATH actually is.

Source Link
Seamus
  • 5.1k
  • 3
  • 23
  • 44

This works on my Ventura system, and it should work on your Monterey system...

I don't think cron has a "log file" per se, and so I'll suggest you get into the habit of creating and using a file to capture the output of stdout and stderr from all cron jobs. It's the best way to troubleshoot mysterious cron issues.

FROM:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2

TO:

0 10 * * * mv /Users/me/Desktop/test /Users/me/Desktop/test2 >> /Users/me/Desktop/test_log 2>&1

The information in the file test_log should contain something useful, and suggest where the issue is. I suspect - in this case - it's something simple.

Here's the breakdown on the addition:

  • >> a redirect (with augmentation instead of replacement)

  • 2>&1 redirect stderr to stdout; effectively combines both streams into a single stream