NeODarK's picture
NeODarK - Wed, 2022/09/28 - 14:42

Hi, I have some machines with Turnkey Linux and I receive all days cron apt emails about updates...

How I can disable this emails but still receiving any error update email?

Thanks!!

Forum: 
General
Jeremy Davis's picture

Jeremy Davis - Mon, 2022/10/03 - 04:42

Apologies on my slow response... I'm not sure how or why, but it appears that I missed your post. Apologies about that.

To be honest, I'm not 100% sure about achieving your ends. As you note, we use cron-apt. The actual cron job that get's triggered is /etc/cron.daily/apt-compat, which then in turn triggers /usr/lib/apt/apt.systemd.daily to actually check for updates and install them.

So my guess is that to only get emails for errors, you want to change the last line in /etc/cron.daily/apt-compat so that stdout (normal output) is suppressed. That should mean that no email is sent, unless there is output to stderr (error output). I'm not 100% sure it'll work so you'll need to test.

For testing, moving the jo0b (temporarily) to hourly might tighten up the feedback look a bit (creating a cron job to run every minute is probably even better, but not quite as simple to configure, so I'll leave that for you).

mv /etc/cron.daily/apt-compat /etc/cron.hourly/apt-compat

Then edit the last line from this (what it should look like by default):

exec /usr/lib/apt/apt.systemd.daily

To this:

exec /usr/lib/apt/apt.systemd.daily 1>/dev/null

Hopefully that does the trick. If not, please post back and I'll have a bit more of a dig myself.

rhopejr_1910168's picture

rhopejr_1910168 - Mon, 2023/01/16 - 21:39

I have tried this editing the last line, but I still receive the same emails daily. Do you have another suggestion?

Jeremy Davis's picture

Jeremy Davis - Tue, 2023/01/17 - 04:58

The line I've shared above should trap stdout (standard output) and only forward stderr (standard error). That's not 100% infallible, but generally should ensure that there is only error message output.

So if you are getting emails (and my initial understanding is correct), they should be documenting some sort of error or warning message. Is that the case?

Perhaps manually run 'apt update" to ensure that there aren't any warning or errors. Also, could you please share the text of one of the messages?

jackyjoy's picture

jackyjoy - Wed, 2023/03/22 - 06:42

It should only forward error messages?!

Jeremy Davis - Tue, 2023/01/17 - 04:58

The line I've shared above should trap stdout (standard output) and only forward stderr (standard error). That's not 100% infallible, but generally should ensure that there is only error message output.

So if you are getting emails (and my initial understanding is correct), they should be documenting some sort of error or warning message. Is that the case?

Perhaps manually run 'apt update" to ensure that there aren't any warning or errors. Also, could you please share the text of one of the messages?

 

thanks my issue has been fixed.

jackyjoy's picture

jackyjoy - Wed, 2023/04/05 - 21:19

The line I've shared above should trap stdout (standard output) and only forward stderr (standard error). That's not 100% infallible, but generally should ensure that there is only error message output.

So if you are getting emails (and my initial understanding is correct), they should be documenting some sort of error or warning message. Is that the case?

Perhaps manually run 'apt update" to ensure that there aren't any warning or errors. Also, could you please share the text of one of the messages.


 

thanks for the awesome information.

 

thanks my issue has been fixed.

Rohan's picture

Rohan - Thu, 2023/03/30 - 03:27

Here is email I get as example. There is no error stated

CRON-APT RUN [/etc/cron-apt/config]: Wed Mar 29 08:06:01 EDT 2023
CRON-APT SLEEP: 1267, Wed Mar 29 08:27:08 EDT 2023
CRON-APT ACTION: 5-install
CRON-APT LINE: /usr/bin/apt-get -o quiet=1 autoclean -y
Reading package lists...
Building dependency tree...
Reading state information...
CRON-APT LINE: /usr/bin/apt-get -o quiet=1 dist-upgrade -y     -o APT::Get::Show-Upgraded=true     -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/security.sources.list     -o Dir::Etc::sourceparts=nonexistent     -o DPkg::Options::=--force-confdef     -o DPkg::Options::=--force-confold
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following package was automatically installed and is no longer required:
  linux-image-5.10.0-14-amd64
Use 'apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Jeremy Davis's picture

Jeremy Davis - Tue, 2023/04/04 - 03:54

Did you change the file as suggested in my previous post?

I.e. change the last line of /etc/cron.daily/apt-compat to:

exec /usr/lib/apt/apt.systemd.daily 1>/dev/null

If not, please apply that change and then see how it goes. If it works, it'd be great if you could confirm. If you are still getting messages after making the change, then please post back.

Rohan Hope's picture

Rohan Hope - Sat, 2023/04/29 - 18:16
Yes, I changed the file as suggested and I am still receiving the same email daily.   This was most recent email from this morning
CRON-APT RUN [/etc/cron-apt/config]: Sat Apr 29 08:06:01 EDT 2023 CRON-APT SLEEP: 1499, Sat Apr 29 08:31:00 EDT 2023 CRON-APT ACTION: 5-install CRON-APT LINE: /usr/bin/apt-get -o quiet=1 autoclean -y Reading package lists... Building dependency tree... Reading state information... CRON-APT LINE: /usr/bin/apt-get -o quiet=1 dist-upgrade -y     -o APT::Get::Show-Upgraded=true     -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/security.sources.list     -o Dir::Etc::sourceparts=nonexistent     -o DPkg::Options::=--force-confdef     -o DPkg::Options::=--force-confold Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... The following package was automatically installed and is no longer required:   linux-image-5.10.0-14-amd64 Use 'apt autoremove' to remove it. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Birger Krägelin's picture

Birger Krägelin - Mon, 2023/07/10 - 10:45
I stumbled about the same issue and tried Jeremy's suggestion, this does not work. In modern Debian systems the cron job does nothing except resetting a systemd timer. So redirecting does not help because /usr/lib/apt/apt.systemd.daily never generates any output. The email is generated not by cron but by cron-apt. You can see that on the subject line of your email: 
Subject: CRON-APT completed on <your system> [/etc/cron-apt/config]
So just edit your /etc/cron-apt/config file and change the trigger: 
MAILON="error"
Dear auntie Google will help you with different settings.
Jeremy Davis's picture

Jeremy Davis - Wed, 2023/07/12 - 01:30

Thanks for your input Birger. FWIW I was aware that cron-apt was generating the message, but I was under the impression that the message was sent by cron?! Your post suggests that that may not be the case?

The only thing that makes me doubt your suggestion is that the default cron-apt config that we ship is:

MAILON="never"

Which would suggest to me that by default cron-apt itself should never send any emails!? Was yours MAILON="never" too before you updated it to MAILON="error"?

Birger Krägelin's picture

Birger Krägelin - Wed, 2023/07/12 - 09:41
Thanks Jeremy, I just checked it in my environment (LXC, 17.9). A brand new installation in fact shows 
MAILON="never"
I was surprised, because I did change 
MAILON="output"
Just to verify I did inspect etckeeper using 
git log
I could see a lot of commits, starting with initial commit. The first daily autocommit shows the change from "never" to "output" This commit is the first one after initial configuration. It shows activity enable_secalerts, and you can find: 
/usr/lib/inithooks/bin/secalerts.sh:

configure_cronapt "MAILON" "output"
So both is true. TKL has initial configuration "never", but every running system has configuration "output". I would like to see "error" in the upcoming TKL 18 BTW, many thanks to Jeremy for TKL
Jeremy Davis's picture

Jeremy Davis - Thu, 2023/07/13 - 02:02

Initially I was going to argue with you (before I read your post properly) - because I have a number of TKL servers running and can confirm that they all have 'MAILON="never"' in their cron-apt config. However, the other part of your post assists me to realise what is going on.

You are almost right, but not quite. As I note above, I have numerous local TKL servers running and they all have 'MAILON="never"'. However, as you note, inithooks/bin/secalerts.sh does set that to 'MAILON="output"', however, that is only run WHEN the "Security Alerts" are enabled during the firstboot scripts! I.e. when you get to the "System Notifications and Critical Security Alerts" question, select "Skip" (by hitting the tab key until it's highlighted).

Unfortunately, re-running that (and skipping it) doesn't undo the enabling. So your input (on noting how to disable the MAILON setting) is indeed really valuable. I will think a bit more about this and probably look at including a confconsole plugin to undo what the "Security Alerts" inithook does.

Thanks again

Rohan Hope's picture

Rohan Hope - Fri, 2023/07/14 - 00:41
Thanks! I saw mine is set to 'MAILON="output"'. I changed to 'MAILON="error"'. I will report back tomorrow or Sat if this worked.
Rohan Hope's picture

Rohan Hope - Mon, 2023/07/17 - 03:28
I changed config to below and now the daily emails stopped. So it seems to be working. Thanks! 
MAILON="error"
Jeremy Davis's picture

Jeremy Davis - Tue, 2023/07/18 - 00:07

Thanks for the confirmation that it works for you too Rohan!

Add new comment