I would like to have SCALE send an email at startup (after booting). The reason is that SCALE rebooted randomly recently due to a memory error that cause a kernel panic. I don’t know if it was a one-off fluke or a more serious problem; so I would like to get notified whenever SCALE boots. Does anyone know how to do this?
If I can send an email from the command line, then I can do so at startup by adding an INIT script under System, Advanced. So I just need to know how to do so from the command line.
Incidentally, I have learned how to send an email from the SCALE CLI as discussed here: Mail |
However, this does not help because, at least as I understand it, the SCALE CLI is interactive only and cannot be scripted.
I should have thought of this, but the OPNsense router that provides internet access to my house is virtualized as a VM on the SCALE server that’s the subject of this post. Since it takes a while for OPNsense to boot up after SCALE boots up, it’s necessary to pause the INIT script before sending the email in order to give OPNsense time to boot, or else the email doesn’t send. I chose a 600 second (10 minute) delay, which was overkill in my case.
In case anyone else is in this situation, here is the modified script that delays before sending the email: sleep 600 && echo “The server booted up at $(date)” | mail -s “TrueNAS Bootup Notice” someone@example.com
Is this answer still valid in current releases of TrueNAS SCALE (Electric Eel)? I ask because I search for exactly that functionality.
Email server settings + auth are set correctly, Test emails go out and are received fine.
When I try the suggested command on CLI (with a valid receiver email of course) the command is accepted without error, but does not result in a sent email.
I tried to find errors in the “Audit”-section in the GUI and also in several log files in /var/log on CLI, but couldn’t find anything.
How can I troubleshoot further - any specific place where to look?
Even though my outgoing email server are correctly set and authenticated and test emails via GUI work fine, above command fails on my system.
In an effort to troubleshoot, I found that I just can add the “-v” switch for debugging and then I get this (someone@example.com is of course replaced by the real recipient address):
root@fractal[~]# echo "The server booted up at $(date)" | mail -v -s "TrueNAS Bootup Notice" someone@example.com
LOG: MAIN
<= root@tnsbuilds01.tn.ixsystems.net U=root P=local S=531
root@fractal[~]# delivering 1to5to-00Dquq-2E
R: nonlocal for someone@example.com
LOG: MAIN
** someone@example.com R=nonlocal: Mailing to remote domains not supported
LOG: MAIN
<= <> R=1to5to-00Dquq-2E U=Debian-exim P=local S=1866
LOG: MAIN
Completed
delivering 1to5to-00Dqut-2J
R: system_aliases for root@tnsbuilds01.tn.ixsystems.net
R: nonlocal for fractal@fp.on.at
LOG: MAIN
** fractal@fp.on.at <root@tnsbuilds01.tn.ixsystems.net> R=nonlocal: Mailing to remote domains not supported
LOG: MAIN
Frozen (delivery error message)
Any idea why this stopped working? Or does it still work for you?
Umm, probably will no longer work? There has been a change for hardening purposes in the mail system in the latest released Scale and most older mail methods and scripts don’t seem to work anymore. If you look up the multi_report thread in the forums, you will see all the work/trial/error that went into the script just to get that script to send email again.
If you come up with something that allows the use of TrueNAS to send an email, including attachments, please make a post in that thread. We would love to have an alternative way, one that is built in. I really miss sendmail.
^^Interesting. I wonder if wireguard is affecting this. The email server is only accessible over the WG tunnel, so wg has to stay up long enough during shutdown for the message to be sent.
Using the above as shutdown command I get mostly failures (no email). Same command in a script (simple bash script which does nothing more than use the same python command line) results in an email each and every time!
I tried a variation of both command and script (prefacing the subject line so I know which one generated the email), this time command work each time as well - 2 emails received for each shutdown. Also, any sleep statements are respected in the script - reboot doesn’t occur until script completion.
Tried a variation where network connectivity is removed (TN in a vm) then reboot issue via console. No delays in rebooting - sendmail.py just fails and moves on.
It would seem the shutdown COMMAND is suitable for things that execute quickly. The documentation doesn’t really give much detail to the difference in execution of either. Obviously a script is a combination of commands, but a command line can also be a combination of commands (separated by && or || ). There’s gray area here.
The final test will be once I go back to the actual live machine and reconnect via mobile data (lots of latency). I think the script method will work.