Jump to content
  • 6.6.6 - Unable to disable sSMTP notifications


    manofcolombia
    • Annoyance

    Since upgrading to 6.6.6, I see this log message every day around the same time:

     

    Jan 8 06:00:13 stylophora sSMTP[4074]: Creating SSL connection to host
    Jan 8 06:00:13 stylophora sSMTP[4074]: SSL connection using ECDHE-RSA-CHACHA20-POLY1305
    Jan 8 06:00:13 stylophora sSMTP[4074]: Authorization failed (535 5.7.8 https://support.google.com/mail/?p=BadCredentials g25sm28692448qki.29 - gsmtp)


    I had never previously setup email notifications for anything so I went and took a look at the notifications page in settings and found that email notifications are all unchecked, however, the default gmail smtp server info is there and with no way to disable it. 

    image.thumb.png.3418bca5f7cf6802faffe6f2ca20592c.png

    image.thumb.png.a53f89cde459e7def7940a3022a9a61b.png

     

    There is no option to disable this in "preset service" and if you choose custom service and blank out all the options, it will not let you save the form. Hitting reset will revert to default gmail preset.

    Expected outcome - like the rest of the notification services, being able to disable the notification types:

    image.thumb.png.0ae831b561c8e3f47c88779aa91bcfb1.png

    stylophora-diagnostics-20190108-1911.zip



    User Feedback

    Recommended Comments

    When no email is selected, it should not run the sstmp daemon.

    Can you post the output of

    cat /etc/cron.d/root
    
    cat /boot/config/plugins/dynamix/dynamix.cfg

     

    Share this comment


    Link to comment
    Share on other sites

    Here you go

     

    root@stylophora:~# cat /etc/cron.d/root
    # Generated docker monitoring schedule:
    10 0 * * * /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php check &> /dev/null
    
    # Generated system monitoring schedule:
    */1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null
    
    # Generated mover schedule:
    0 0 * * * /usr/local/sbin/mover &> /dev/null
    
    # Generated parity check schedule:
    0 6 5 * * /usr/local/sbin/mdcmd check  &> /dev/null || :
    
    # Generated plugins version check schedule:
    10 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck &> /dev/null
    
    # Generated unRAID OS update check schedule:
    11 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null
    
    # Generated cron settings for docker autoupdates
    0 4 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateDocker.php >/dev/null 2>&1
    # Generated cron settings for plugin autoupdates
    0 3 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1
    # Generated ssd trim schedule:
    0 6 * * * /sbin/fstrim -a -v | logger &> /dev/null
    root@stylophora:~# cat /boot/config/plugins/dynamix/dynamix.cfg
    [display]
    date="%c"
    number=".,"
    scale="-1"
    tabs="1"
    users="Tasks:3"
    resize="0"
    wwn="0"
    total="1"
    usage="1"
    banner="image"
    dashapps="icons"
    theme="black"
    text="1"
    unit="C"
    warning="70"
    critical="90"
    hot="45"
    max="55"
    font=""
    header=""
    [notify]
    entity="1"
    normal="1"
    warning="1"
    alert="1"
    unraid="1"
    plugin="1"
    docker_notify="1"
    report="1"
    display="0"
    date="d-m-Y"
    time="H:i"
    position="top-right"
    path="/tmp/notifications"
    system="*/1 * * * *"
    unraidos="11 0 * * *"
    version="10 0 * * *"
    docker_update="10 0 * * *"
    status=""
    [parity]
    mode="3"
    hour="0 6"
    write=""
    day="1"
    dotm="5"

     

    Edited by manofcolombia

    Share this comment


    Link to comment
    Share on other sites

    Rather than trying to get these to go away, you really should configure it so you get at least warnings and alerts by email or other agent. You need to know immediately when Unraid detects a problem instead of waiting until you happen to see it in the webUI. People who don't know when they get their first problem are the people who wind up with multiple problems they can't recover from.

    Share this comment


    Link to comment
    Share on other sites
    22 minutes ago, trurl said:

    Rather than trying to get these to go away, you really should configure it so you get at least warnings and alerts by email or other agent. You need to know immediately when Unraid detects a problem instead of waiting until you happen to see it in the webUI. People who don't know when they get their first problem are the people who wind up with multiple problems they can't recover from.

    I would say that this is incorrect. As I could have other monitoring in place - which I do - and/or if I select a different notification agent, such as push bullet, I could/would want to disable email notification so I wouldn't be getting duplicate notifications. 

    Share this comment


    Link to comment
    Share on other sites
    59 minutes ago, manofcolombia said:

    I would say that this is incorrect. As I could have other monitoring in place - which I do - and/or if I select a different notification agent, such as push bullet, I could/would want to disable email notification so I wouldn't be getting duplicate notifications. 

    I agree this should be fixed. But DO you have other monitoring? It doesn't look like you have another agent configured from that screenshot. That is the point I was making. You need to get notified.

    Share this comment


    Link to comment
    Share on other sites
    4 hours ago, manofcolombia said:

    Here you go

    These settings are correct and can not cause an email to be sent every day at 06:00am.

    Can you also post the output of

    crontab -l

    From which version did you upgrade to 6.6.6?

    Edited by bonienl

    Share this comment


    Link to comment
    Share on other sites
    On 1/9/2019 at 12:43 PM, bonienl said:

    These settings are correct and can not cause an email to be sent every day at 06:00am.

    Can you also post the output of

    
    crontab -l

    From which version did you upgrade to 6.6.6?

    # 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:
    40 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:
    30 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:
    20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
    0 5 * * 6 /usr/local/emhttp/plugins/ca.backup2/scripts/backup.php &>/dev/null 2>&1

     

    Share this comment


    Link to comment
    Share on other sites
    On 1/9/2019 at 12:28 PM, trurl said:

    I agree this should be fixed. But DO you have other monitoring? It doesn't look like you have another agent configured from that screenshot. That is the point I was making. You need to get notified.

    Yea I do. Between what I pull into grafana and ELK and don't have too much need for the built in notifications. And I log in basically daily.

    Share this comment


    Link to comment
    Share on other sites

    Everything looks alright and I can't determine why or what is sending the email.

     

    Can you - as part of the troubleshooting exercise - set up your email and see which notification you receive?

    Share this comment


    Link to comment
    Share on other sites


    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.