Unattended upgrades won’t use mailx when run by Systemd

Your question is a variation of the FAQ Why do things work differently under systemd?.

One of the benefits of systemd is that it provides a consistent execution environment. To error on the side of security and simplicity, the environment variables set are minimal.

The related docs on the systemd execution environment detail what's set.

You mentioned that your configuration was in the root home directory. man mailx confirms It is looking in ~/.mailrc, as opposed to the fixed path /root/.mailrc.

The systemd docs clarify that the $HOME variable is only set when the User= directive is used. You did not share your systemd service file, but I presume since you are running the task as root you did not use the User= directive. So that could explain part of your issue.

It also appears that a path you want may not be set by your $PATH environment variable when run by systemd. You can confirm this by replacing the ExecStart= line in your service with:

 ExecStart=/bin/echo "My path is $PATH"

If the mailx path is not listed, you can explicitly set with an Environment= directive.

If this explicit tips don't solve your issue, be sure to check out the FAQ linked above for more possibilities.

I use msmtp and bsd-mailx on Ubuntu 18.04 to allow unattended-upgrades to email me on updates. I think I ran into the same problem as you. I configured msmtp and I could send email using mailx from the command line. unattended-upgrades would also send me an email if I ran it myself from the command line, but if unattended-upgrades would run automatically then I would receive no email. Looking in the logs of /var/log/msmtp/msmtp.log I saw:

<DATE> host=<MY_SMTP_HOST> tls=on auth=on user=<MY_STMP_USERNAME> from=<MY_EMAIL_ADDRESS> recipients=<MY_EMAIL_ADDRESS> smtpstatus=550 smtpmsg='550 5.2.0 Mail format error: No domain in From header [1633]' errormsg='the server did not accept the mail' exitcode=EX_UNAVAILABLE

So there is a problem setting the From header. Diving into this it appears that the from email address used by unattended-upgrades defaults to root, but you can define this yourself in /etc/apt/apt.conf.d/50unattended-upgrades by adding Unattended-Upgrade::Sender "<EMAIL_ADDRESS>";. This fixed it for me.