Send email from command line or at startup in SCALE

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.

Maybe something like this?

echo "The server booted up at $(date)" | mail -s "TrueNAS Bootup Notice" someone@example.com

This assumes (and requires) that you have outgoing email server settings and authentication configured in TrueNAS.

4 Likes

Winnielinnie you’re a hero as usual. That worked.

I need to come up with a personal icon for the new forum, and this time I won’t use Linux Mint to step on your game like in the old forum.

1 Like

I think it was cool when we both had similar avatars. :grin: Feel free to use it again! No need to ask my permission. Never need to. :vulcan_salute:

I remember the massive protests that erupted. :open_mouth: People flooded the streets!

EDIT: Give my posts a like! I must surpass a certain someone in the leaderboard. :neutral_face:

2 Likes

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

1 Like

On a few customers I have multiple TrueNAS servers, so I’ll use the following, to differentiate between them:

echo "$(hostname) booted up at $(date)" | mail -s "TrueNAS Bootup Notice" someone@example.com

3 Likes

I have a virtual pfsense too.

I use the wait_for_ssh script here:

To start a vm after my pfsense comes online.

Same thing could work well for you.

1 Like

Is this answer still valid in current releases of TrueNAS SCALE (Electric Eel)? I ask because I search for exactly that functionality.

  1. Email server settings + auth are set correctly, Test emails go out and are received fine.
  2. 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.
  3. 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.

1 Like

I found the thread which describes a working solution for sending mail:

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.

1 Like

Last week i upgraded to EE , and now i was bitten by the missing sendmail too.

I used winnie’s mail command above on DF , to send a “Bootup” & “Shutdown” e-mail. But no dice on EE.

I grabbed the “Oxyde” magic mail program from here (thnx) joe & oxyde:

https://github.com/oxyde1989/standalone-tn-send-email

chmod +x , and dumped it in /root
Initially i would have placed it in /usr/local/bin , but /usr is mounted ro :roll_eyes:

As explained on the github page you’d need extra permissions to run the script successfully.

But as expected the “init/shutdown stuff runs at elevated privileges”

This “command” seems to work for me in the init/shutdown scripts

python3 /root/multireport_sendemail.py     --subject "TrueNAS Bootup Notice"     --to_address "nas-01@xxx"     --mail_body_html "$(hostname) booted up at $(date)" 

Edit:

I have just run one reboot cycle , where it worked on both boot & shutdown.
Maybe i was lucky, as I haven’t seen the issues mentioned here

1 Like

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

Could be …

I just finished my weekly backups, and shutdown the servers.
I received shutdown e-mails from both of them

What is the exact command line you’re using for the shutdown email? For “when”, it’s set to shutdown, for type, “command”?

I tried testing without wireguard even running, still nothing. This is on 24.10.2

I use the above as the command in the init / shutdown scripts.
Well adapted text for shutdown.

I use GUI to shutdown the machines

Ohh: I run
TrueNAS ElectricEel-24.10.2.1

This is wild!

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.

I do have a local e-mail (linux mail) server, so my “mail accept” would be immediately. If that would have any impact …

But as you mentioned “Sleep” was respected , so it seems there’s no parallelism there.

Oxyde also mentions using a script, since command gave him problems too.

He was on FT.

Did you see that i’m one EE update further ahead ?
Could IX have tweaked shutdown ?

I’ve been testing with EE from the getgo.

It didn’t click in my mind to run the script as a script, not as a command until earlier today. After all, a script can be called by a command ;).