3

On a Debian Stretch server, APT ist configured via /etc/apt/apt.conf.d/10periodic to automatically update itself every day. Hadn't I run "apt-get update" manually by chance, I wouldn't have noticed this error:

W: Failed to fetch https://packages.sury.org/php/dists/stretch/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743 

I downloaded the updated GPG key to fix the problem, but I need a way to be informed by APT when things go wrong. The server was missing two PHP updates because of this.

https://wiki.debian.org/UnattendedUpgrades mentions "APT::Periodic::Verbose", but this doesn't allow to only be notified about errors (and I really don't need a mail from all 50 servers every day...)

edit 2019-05-13: The package unattended-upgrades is not installed, and I don't want to use it. APT should only update itself, not upgrade.

6
  • Wasn't there some switch like MailOnlyOnError for UA? Can't check it locally atm Commented May 9, 2019 at 15:31
  • afaics, this only applies to "Unattended-Upgrade" which I don't want to use. Only automatic update of the packages-list, no upgrade. Commented May 9, 2019 at 15:33
  • Hm. Why do you use unattended upgrades then, and not something like cron-apt? Commented May 9, 2019 at 15:54
  • Again, I'm not using unattended upgrades. Only updates. Commented May 10, 2019 at 21:31
  • ...yes, obviously using the package "unattended upgrades", which you yourself linked in your question. As of Debian 9 (Stretch) both the unattended-upgrades and apt-listchanges packages are installed by default Commented May 10, 2019 at 21:36

1 Answer 1

1

Setting APT::Update::Error-Mode "any" will turn warnings into errors (apt-get update exits with non-zero code).

It further depends on the system configuration and the way updates are run. Check if the update is being run through a systemd service (/lib/systemd/system/apt-daily.service) and if that service runs /usr/lib/apt/apt.systemd.daily update command. If yes, logic of that script touches /var/lib/apt/periodic/update-stamp in case apt-get update was successful. Since apt-get update was already configured to fail on warnings, the file will not be touched in case of warnings/errors.

So to notify on failed update, status of that file can be checked after the service stops. Create /etc/systemd/system/apt-daily.service.d/override.conf:

[Service] ExecStopPost=/some/path/check_if_apt_update_successful 

That will execute the custom script that checks whether the update succeeded:

curr=$(date '+%s') touchedFile="/var/lib/apt/periodic/update-stamp" # send mail if touch was before N seconds ago modificationThresholdSeconds=120 if [ ! -f "$touchedFile" ] || [ $(stat -c %Y -- "$touchedFile") -lt $(($curr - $modificationThresholdSeconds)) ] ; then // send mail here fi 

Additionally setting APT::Periodic::Verbose "2"; might not cause any emails being sent every time the update is run, but just log the update command output. After the mail is sent it is then possible to inspect journalctl -u apt-daily.service for the reason update failed.

3
  • Thanks, I will check this the next days (have to wait for the automatic update between changes) Commented Jul 17, 2024 at 9:18
  • Running systemd (server was upgraded to Debian Bookworm since I first asked this question), but /usr/lib/apt/apt.systemd.daily apparently is not using APT::Update::Error-Mode (stamp file is still touched and has a current date). A manually run apt update now returns an exit code != 0, but nothing changed for the periodic update. Commented Jul 19, 2024 at 8:27
  • On Ubuntu 20 and 22 /usr/lib/apt/apt.systemd.daily just runs apt-get update and checks for output of that command when deciding whether to touch the file. Maybe you could check the source of that script and see how it behaves. Commented Aug 5, 2024 at 19:44

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.