Since upgrading to 6.4.0-rc8q (and also rc9f) I get the following errors in my syslog at the same time each day:

 

 

Sep 26 04:30:07 Northolt sSMTP[59685]: Creating SSL connection to host
Sep 26 04:30:07 Northolt sSMTP[59685]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256
Sep 26 04:30:07 Northolt sSMTP[59685]: Authorization failed (535 5.7.8 https://support.google.com/mail/?p=BadCredentials e29sm5119607edd.28 - gsmtp)
 

The thing is, I don't have email notifications configured as I keep a browser window open on the GUI and all six types of notification are set to Browser only. The SMTP settings are unconfigured. By that, I mean I haven't changed anything from the defaults. This wasn't a problem with 6.3.5 but with the rcs it seems the system is trying and obviously failing to initiate a secure SMTP transaction with Gmail's server. How do I stop this, please?

 

To try to fix this myself, on one server running rc9f I tried to change the SMTP settings to Custom but it complains that I have not set the required fields, so I went back to the Gmail preset. On the other server I tried toggling the Email checkboxes for the six notification types on (click Apply) and then off (click Apply again). I'll check the logs tomorrow to see if either has had any effect. My third server, still running 6.3.5, has its Notification settings set the same way but doesn't show the errors in the log.

Have you looked at the 'Notifications settings' under the 'Notification' page on the 'Settings' tab and make sure that you don't have any of the "E mail" boxes ticked on the bottom?

 

(By the way, it is a good ideal to setup E-mail notifications so that you get an early warning when things start to go south!)

 

I second what Frank said, but would also ask that you provide your system diagnostics so we can review further.

3 hours ago, Frank1940 said:

Have you looked at the 'Notifications settings' under the 'Notification' page on the 'Settings' tab and make sure that you don't have any of the "E mail" boxes ticked on the bottom?

 

Thanks for your reply, Frank. Yes. I believe I said so in my OP.

 

5 hours ago, John_M said:

all six types of notification are set to Browser only

 

Here's a screenshot:

 

 

3 hours ago, jonp said:

I second what Frank said, but would also ask that you provide your system diagnostics so we can review further.

 

Apologies. I should know better. Diagnostics were grabbed soon after a fresh reboot, so the actual sSMTP error messages don't appear. I'll grab them again in the morning. The reason I rebooted is because of another issue mentioned here. My syslog was full of ACPI error messages because I had forgotten to do the tweak necessary to suppress them after the update from rc8q to rc9f. I also get an nginx error message whenever I open the Plugins page, which I attribute to a faulty SNMP plugin.

 

northolt-diagnostics-20170926-2306.zip

 

Thanks, both, for your advice about having email alerts enabled. Whether I decide to follow your advice or not isn't really the issue though and in any case, I might prefer to use a notification agent such as Pushbullet instead of email. I'm testing an rc and I think I've found a bug and I'm reporting it. I think the problem is that a Gmail SMTP configuration is enabled by default, with no valid source or destination email addresses or password.

 

Edited September 26, 20178 yr by John_M
Fixed typo

Diagnostics grabbed this morning, showing the sSMTP error messages at 04:30.

 

northolt-diagnostics-20170927-0907.zip

 

If you have a cron job starting at that time and it fails, it will generate an email notification, regardless of your notification settings.

 

1 hour ago, bonienl said:

If you have a cron job starting at that time and it fails, it will generate an email notification, regardless of your notification settings.

 

Ok, thanks for that. There was something niggling at the back of my mind, a half-remembered discussion I read some time ago which a search failed to find.

 

root@Northolt:~# ls -l /var/spool/cron/crontabs/

total 4

-rw------- 1 root root 1124 Sep 26 23:03 root

root@Northolt:~# crontab -l

# If you don't want the output of a cron job mailed to you, you have to direct

# any output to /dev/null.  We'll do this here since these jobs should run

# properly on a newly installed system.  If a script fails, run-parts will

# mail a notice to root.

#

# Run the hourly, daily, weekly, and monthly cron jobs.

# Jobs that need different timing may be entered into the crontab as before,

# but most really don't need greater granularity than this.  If the exact

# times of the hourly, daily, weekly, and monthly cron jobs do not suit your

# needs, feel free to adjust them.

#

# Run hourly cron jobs at 47 minutes after the hour:

47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null

#

# Run daily cron jobs at 4:40 every day:

30 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null

#

# Run weekly cron jobs at 4:30 on the first day of the week:

40 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null

#

# Run monthly cron jobs at 4:20 on the first day of the month:

50 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null

30 4 3 * * /usr/local/emhttp/plugins/ca.backup/scripts/backup.php &>/dev/null 2>&1

root@Northolt:~# ls -l /etc/cron.daily/

total 12

-rwxr-xr-x 1 root root 3912 Sep 26 23:03 exportrotate*

-rwxr-xr-x 1 root root  129 Aug 29 17:15 logrotate*

-rwxrwxrwx 1 root root   76 Sep 26 23:03 user.script.start.daily.sh*

root@Northolt:~# cat /etc/cron.daily/user.script.start.daily.sh 

#!/bin/bash

/usr/local/emhttp/plugins/user.scripts/startSchedule.php daily

 

So, root is the only user with a crontab. The one that runs daily at 04:30 is /etc/cron.daily, which contains exportrotate, logrotate and user.script.start.daily.sh. The latter looks like the likely culprit. However, the User Scripts plugin's Settings page shows that all schedules are disabled:

 

 

Nevertheless, I'll remove the plugin and see what happens at 04:30 tomorrow morning.

 

Edited September 27, 20178 yr by John_M
fixed typo

There is also an incompatibility between unRAID 6.4rc7+ versions and "exportrotate" (used by Dynamix File Integrity plugin), causing a daily 'error' notification. Need to fix that one day!

 

3 minutes ago, bonienl said:

There is also an incompatibility between unRAID 6.4rc7+ versions and "exportrotate" (used by Dynamix File Integrity plugin), causing a daily 'error' notification. Need to fix that one day!

 

Ah! So exportrotate is the culprit then! I do have Dynamix File Integrity plugin installed. I won't re-install User Scripts just yet though. I'll wait until tomorrow.

 

The same error message was added to the log at 04:30 this morning so the User Scripts plugin was not the cause. It looks as though exportrotate is to blame.

 

I tried running it manually:

 

root@Northolt:~# /etc/cron.daily/exportrotate 

grep: /proc/mdcmd: Input/output error

 

Guilty!

Edited September 28, 20178 yr by John_M
Added test

On 27/09/2017 at 7:09 PM, bonienl said:

There is also an incompatibility between unRAID 6.4rc7+ versions and "exportrotate" (used by Dynamix File Integrity plugin), causing a daily 'error' notification. Need to fix that one day!

 

Until it's fixed then, everyone using the Dynamix File Integrity plugin and unRAID 6.4rc7+ is going to get either the same error in their syslog as I'm getting or else, if they have email notifications enabled, an annoying daily email during the night. As many people receive email on their mobile phone these days and its arrival is often signalled by a loud beep I'm surprised there aren't a lot of people complaining about this!

I've made a fix. Updated version is available.

 

Brilliant! Thank you, I'll update.

That seems to have worked - no more sSMTP error messages in the log. However, having updated the Dynamix File Integrity plugin yesterday, I noticed today (which just happens to be both the first day of the month and a Sunday) that a parity check and a file integrity check are both underway and each is slowing down the other. My DFI plugin is configured to "Don't start" when "Parity operation is running" but that was ignored. So I toggled the option and re-applied it. The next time the first of the month falls on a Sunday is April 2018.

Right, you just discovered a bug. 

 

Corrected and new version available.

Good. I'm glad to help and thank you for fixing it so quickly.