Yes. But is not normal. Which operation system?
Perfectly normal *FreeBSD running FreeNAS and nc installed in its own jail
Pretty sure I posted what OS Im running at the start
Ok. I think i lost the overview and i can not help you. Sorry and bye.
Sort of agree with this, but the cron job is not in place for the purpose of sending out emails - the only reason I even pointing to postfix is that Im using postfix for email sendouts - still no idea how the email to/fro ends up as www@nextcloud.com that lands with my isp outside my knowledge or directive
The cron job should not ever send out an email as far as I can see understand - purpose of even creating the cron job is that nc recommend cron to refresh/sync data and according to doco it MUST(!) be run/owned by www.
Anything else and especially how this 5 or 15 min cycled job ends up sending emails outside my control I dont know - and thats what I am trying to track down.
So any suggestion of creating alternative methods of sending out email as part of the cron comes across as weird and to say the least unnecessary - Expect errors of this job ending up in logs if any and if the job fails I suppose nc would report that pointing to last time the job ran *via the admin gui
But it does. Returns from cronjobs are sent back to the user who set up the cronjob. In your case it is www, and then it completes the mail with the default hostname set by postfix.
Don’t use postfix for this. There are other services that just do that. Surely you can configure postfix as well to do so, but you can do this wrong and then you are sending out spam.
Well you can redirect the output to /dev/null or send it to an address you specify. Everything is under your control but you have to set it up. Please read the answers from topics.
1 Like
1 Like
Jep sending mails on any cron jobs output is simply the default behaviour of cron. The above link contains the IMO best solution to prevent this:
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.~
EDIT: To get information in syslog/journal about a failed cron job, you need to assure that errors are logged by using option “-L 5” (one log for job start, one log in case if exits with != 0). On most distros, this can be done in /etc/default/cron. The comment “0 no logging (errors are logged regardless)” is a bid misleading since it is about STDERR to mail and not about adding an info to syslog/journal.
1 Like
Thanks - Finally an explanation I actually understand and make sense - Always something new to learn 
Did not know cron had this built in - Now it makes perfect sense and thanks for pointing to a solution.
Btw. what does that mean with cron jobs scheduled via FreeNAS gui? Suppose any fault would go out to freenas root mail configuration or would something similar take place is it runs under some other cridentials such as www?
Can you please explain the solution and how it is related to nextcloud?
It’s quite simple really For whatever unknown reason nc got blown away i.e entire content apart from the directory structure /usr/local/www/nextcloud/ was empty. - All I can related this to is that I somehow, for whatever unknown reason decided to update php from 72 to 73 (looking at logs it appears this was done a month or two earlier and I havent made an attempt to login and use nc.
BUT(!), since the crontab and the cron job still were in place scheduled to run every 15 minutes where it pointed to the /usr/local/www/nextcloud/cron.php that no longer existed the cron job started firing off emails to www@iinet.net.au
*/15 * * * * /usr/local/bin/php -f /usr/local/www/nextcloud/cron.phpThe email, according to my isp, looked like this
Cron <www@nextcloud> /usr/local/bin/php -f /usr/local/www/nextcloud/cron.php
>Could not open input file: /usr/local/www/nextcloud/cron.phpSo, now when it was explained that cron have this built in, in case of errors, it makes sense.
Cron will not use my defined userid specified in postfix - rather use www as the user, since the cron executes under that user.
So, to prevent anything like this to happen in the future *for nc or other apps that have cron jobs scheduled, I will start adding MAILTO="" at the top of all my existing and future cron jobs.
btw. Defining a cron job is recommended by nc and its purpose is simply to refresh and synchronize data the whole issue could have been avoided by sticking to AJAX
Perhaps wrong permissions.
Post
ls -l /usr/local/www/nextcloud/cron.php
Nop! nc is blown away when upgrading from php72 to 73 - Think this happened as part of me adding imagick that was reported as missing as part of an earlier nc upgrade. And I probably ended up installing php73-pecl-imagick instead of php72-pecl-imagick.
Not a big deal since all my nc configurations and db is tucked away securely outside /usr/local/www/nextcloud
So shouldnt take much to get it up and running again.
BUT(!) the issue was caused by the missing /usr/local/www/nextcloud/cron.php that the cron job tried to execute.
Please post the output of the command.
I suppose I did
- pkg update
- pkg upgrade
- upgraded nc as part of step 2 (alternatively I did “pkg upgrade nextcloud-php72”
- logged in to nc and got a warning about missing imagick
- 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
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!!!
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.
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.
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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.