Cron job attemtping to send email every 5 minutes

[duffbeer59]

@tflidd

Don’t do that. This is probably not your domain (and never use someone else’s domain name here, no wonder they get angry!!!). Please only use your own domain. If you don’t want to run your own mailserver (and if you want, get to know the subject a bit better before by setting up a local mailserver in your local network only), use a mail-relay-server such as ssmtp instead.

hm, $myorigin assignment is actually used by postfix to send me email messages - Its my isp domain its pointing to and together with my account name this should be perfectly ok - And it works perfectly - *but still dont understand why an email is sent as part of the cron job ?
It shouldn’t!!!
And why is it constructing an email to/from as www@iinet.net.au (as shown in the mail log)

btw. When legit email is sent the log show up as root@iinet.net.au and weirdly enough I actually receive these emails in my legit inbox

[tflidd]

@duffbeer59

• but still dont understand why an email is sent as part of the cron job ?
  It shouldn’t!!!
  And why is it constructing an email to/from as www@iinet.net.au (as shown in the mail log)

When the command of the cronjob is returning some output, it is send back to the user running the cronjob. The user is www, the hostname in postfix iinet.net.au:

@duffbeer59

# For the sake of consistency between sender and recipient addresses,
# myorigin also specifies the default domain name that is appended
# to recipient addresses that have no @domain part.

@duffbeer59

Its my isp domain its pointing to and together with my account name this should be perfectly ok

NO! Only use your own domains (or subdomains) for that!

@duffbeer59

And it works perfectly

You must be kidding me, your provider already called you because you spammed them with mails.

If you have your own domain or subdomain (you usually get it with your server anyway, if not for nextcloud it is nice to have one and not very expensive (1 €/$ per month). Or use ssmtp that sets the addresses correctly and was done for such purposes.

[devnull]

I think the problem is not the Mailing but the cron process.
I wrote you must stop all cron processes, execute the cron.php manually and find all errors or send them to /dev/null.

mail setting iinet.net.au (not interesting for the problem):
https://help.iinet.net.au/email-settings

[tflidd]

There are different problems. It’s a good idea to get the return of certain cronjobs in case of errors. I also wrote how you can change the e-mail address or you redirect to /dev/null.

The mailserver is just dangerous like that. Other processes that generate mails, or the nextcloud notification mails, you want to have something properly set up. You involuntarily send out a lot of spam to other users, best case other provider just block your server, worst case, they just block a whole ip range which will also concern other customers of your ISP.

[duffbeer59]

@tflidd

You must be kidding me

What I mean is that postfix works when it is used to send out emails, such as Aide.
I still dont understand why an email is sent out as part of the cron job dedicated to syncronize nc.
It not suppose to do so!
I tried to execute the php manually and it didnt pick up any error.
When I send out a test email from the command line *that in effect use postfix and the settings such as the mail server domain, it works perfectly. postfix really use my account name and the domain to construct the recipient email.
So if the cron fail for some reason, I didnt expect an email to be sent out - rather the issue being logged.
If you think the postfix setting is wrong and considering I dont have a registered domain or own mail server running, then how do you suggest I configure this?
I use postfix on other services in other jail and they all configured this way and it works.

[devnull]

@duffbeer59

*/15 * * * * /usr/local/bin/php -f /usr/local/www/nextcloud/cron.php

I think a have lost the overview.
but please change

/usr/local/bin/php
to
/usr/bin/php

Perhaps there is an error but with an error also command line must be wrong unless you only used “php” in command line.

Post again

which php

[duffbeer59]

@devnull

but please change

/usr/local/bin/php
to
/usr/bin/php

Perhaps there is an error but with an error also command line must be wrong unless you only used “php” in command line.

Pointless changing this since php is installed exactly where Im pointing to

root@nextcloud:~ # which php
/usr/local/bin/php

[devnull]

Yes. But is not normal. Which operation system?

[duffbeer59]

@devnull

Yes. But is not normal.

Perfectly normal *FreeBSD running FreeNAS and nc installed in its own jail

Pretty sure I posted what OS Im running at the start

[devnull]

Ok. I think i lost the overview and i can not help you. Sorry and bye.

[duffbeer59]

@devnull

I think the problem is not the Mailing but the cron process.

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

[tflidd]

@duffbeer59

but the cron job is not in place for the purpose of sending out emails

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.

@duffbeer59

I even pointing to postfix is that Im using postfix for email sendouts

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.

@duffbeer59

5 or 15 min cycled job ends up sending emails outside my control

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.

[MeiRos]

How To Disable eMail Alert By Crontab Command on Linux/Unix - nixCraft

[MichaIng]

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.

[duffbeer59]

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?

[u_n_glaublich]

Can you please explain the solution and how it is related to nextcloud?

[duffbeer59]

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

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

So, 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

[devnull]

@duffbeer59

>Could not open input file: /usr/local/www/nextcloud/cron.php

Perhaps wrong permissions.

Post
ls -l /usr/local/www/nextcloud/cron.php

Could not open input file: occ

[duffbeer59]

@devnull

Perhaps wrong permissions.

Post
ls -l /usr/local/www/nextcloud/cron.php

Could not open input file: occ

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.

[devnull]

Please post the output of the command.