5

I have setup unattended-upgrades on servers running Raspbian (Raspbian GNU/Linux 9.4 (stretch)). Version of Unattended-upgrades: 0.93.1+nmu1

Updates work, but I am having problems with the email reporting. I want to use mailx for sending reports. If I run the update with command unattended-upgrade -v -d the report gets sent and it uses the email configuration I have in /root/.mailrc.

When unattended upgrades are run by the Systemd timer (apt-daily-upgrade.timer), however, it won’t use mailx.

If sendmail is present it is used to send the mail. In that case, the mail gets sent, but the sender is root@hostname and the messages get flagged as spam.

If there is no sendmail I see this error in journal of apt-daily-upgrade: 

Cannot start "/usr/sbin/sendmail": executable not found (adjust *sendmail* variable)

I cannot understand why different mail programs gets used depending on how the task was started.

I have tried to edit unattended-upgrades Python program to force it use mailx:

if os.path.exists(SENDMAIL_BINARY): ret = _send_mail_using_sendmail(from_email, to_email, subject, body) elif os.path.exists(MAIL_BINARY): ret = _send_mail_using_mailx(from_email, to_email, subject, body

I changed the variable SENDMAIL_BINARY to point to a non-existing path so it would forced to use mailx. This too worked when invoked unattended-upgrades manually but failed when it was run by Systemd. (And the above error about trying to use sendmail still gets logged.)

How can I force unattended upgrades to use mailx even when is run automatically by systemd and what is causing the difference in Mail program that gets used?

EDIT:

System unit file that runs Unattended upgrades:

[Unit] Description=Daily apt upgrade and clean activities Documentation=man:apt(8) ConditionACPower=true After=apt-daily.service [Service] Type=oneshot ExecStart=/usr/lib/apt/apt.systemd.daily install KillMode=process TimeoutStopSec=900
Improve this question

2 Answers 2

Reset to default
3

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.

Improve this answer
1
  • I ended up solving my problem by running unattended-upgares from Crontab instead of Systemd as that worked right away without any issues. But I belive I tips of this answer explain my issues when using Systemd. If I have time I might try them in practice later. Commented Apr 16, 2018 at 14:48
3

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.

Improve this answer
1
  • Thank you so much! You problem is different than the one of the OP, but the same as mine (; Commented Apr 13 at 22:12

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.