Cron job attemtping to send email every 5 minutes

[duffbeer59]

I suppose I did

1. pkg update
2. pkg upgrade
3. upgraded nc as part of step 2 (alternatively I did “pkg upgrade nextcloud-php72”
4. logged in to nc and got a warning about missing imagick
5. now guessing Might have done pkg install php73-pecl-imagick *resulting in php73 got installed that in effect removed php72 and nc

By memory I did the similar thing during an earlier install of nc where I started with installing php72 and down the installation decided to upgrade from php72 to 73 that blew away nc in the exact same manner

[devnull]

@duffbeer59

Cron <www@nextcloud> /usr/local/bin/php -f /usr/local/www/nextcloud/cron.php
>Could not open input file: /usr/local/www/nextcloud/cron.php

Please post:
ls -l /usr/local/www/nextcloud/cron.php

[duffbeer59]

@devnull

Please post:
ls -l /usr/local/www/nextcloud/cron.php

Is it really that difficult to understand that the entire www/nextcloud got blown away as part of the php upgrade? There’s no content left of the …/www/nextcloud/ content *including cron.php in the directory - hence the cron is throwing the error.
Permission is not and have never been an issue once the content is there - but as we speak theres nothing there

I do appreciate the ones trying to find answers to my problem - but most until real answer turned out to be 100% guess work sending me away to question my own sanity at times.
The real answer bogs down to how cron processes handle exceptions that I were unaware of - but now learned - so Id like to thank everyone who had some input on this - especially the ones giving me a valid explanation - My long bow of postfix have in other words nothing to do with this and the input on the mail domain within my postfix config that some seem to object of had nothing, nada to do with the issue - not a postfix issue, but a cron task behaviour I was completely unaware of - but now when I know, I know and its useful - so thanks everyone!!!

[tessus]

@MichaIng

@MichaIng

Add MAILTO="" to the start of the crontab, that’s it.

Redirecting all to /dev/null IMO is suboptimal since you usually want to know if a cron job fails.

I don’t understand this statement.

Adding mailto="" to the top of the crontab is the same as redirecting all to /dev/null.
So you won’t see, if a cronjob fails either way.

[duffbeer59]

@tessus

Adding mailto="" to the top of the crontab is the same as redirecting all to /dev/null.
So you won’t see, if a cronjob fails either way.

I suppose that If keen receiving an email every 5 minutes recommended schedule of the cron according to nc’s admin system page, then add a valid email address - nc’s admin page will most likely report back last cron run and if it exceed expectation it will be reported back in red and as a warning.

[MichaIng]

You’re right, reviewing the configs I was mislead by:

#   0   no logging (errors are logged regardless)

Besides the mail, there is nothing logged.

To assure that one gets a syslog/journal entry when a job failed, e.g. -L 5 cron command option is required (1=job start log + 4=non-zero exit log), usually via /etc/default/cron. But indeed this does not log STDERR to syslog but only adds a single entry, based on exit code like:

(CRON) error (grandchild #398 failed with exit status 127)

So redirecting all STDOUT+STDERR has indeed the exact same effect and MAILTO="" is then only an alternative if the crontab contains a lot of jobs/pipes to skip adding redirects to all of them.

@duffbeer59
As long as its only about the Nextcloud cron job indeed, the admin panel shows a warning as well, however usually there are other jobs and one might want to apply a solution for all of them.