Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Timer doing apt update

36 views
Skip to first unread message

Erwan David

unread,
Feb 19, 2024, 2:50:06 AMFeb 19
to
Hello,

After each boot, the equivalent of apt update is automatically done in
background, through policykit (apt database is locked by policykitd). So
I think there is a timer triggroing this. I'd like to disable this when
my laptop is on expensive link (eg 4G link, or abroad). So I'd like to
disable this timer, but I did not find it. If someone knws better than me...


--
Erwan David

Anssi Saari

unread,
Feb 19, 2024, 4:00:06 AMFeb 19
to
If you're using the package unattended-upgrades (I'm not sure it ties to
policykitd), then there are instructions in the Debian wiki at
https://wiki.debian.org/UnattendedUpgrades#Modifying_download_and_upgrade_schedules_.28on_systemd.29

The timers in question are apt-daily.timer and apt-daily-upgrade.timer.

Come to think of it, just running apt update shouldn't generate much
traffic.

Max Nikulin

unread,
Feb 19, 2024, 12:10:07 PMFeb 19
to
Perhaps I missed something since I have no idea why policykit (or
polkit?) is involved.

You may disable apt timers

systemctl disable --now apt-daily.timer apt-daily-upgrade.timer

Perhaps it is possible to write a script that will respect
connection.metered property set by NetworkManager.

Erwan David

unread,
Feb 19, 2024, 2:40:05 PMFeb 19
to
Sorry il was packagekit, I made a mistake while writing.

I disable the timers, thanks

I'll have a look at connection.metered

Andy Smith

unread,
Feb 19, 2024, 8:00:07 PMFeb 19
to
Hi,

On Mon, Feb 19, 2024 at 08:35:18PM +0100, Erwan David wrote:
> Sorry il was packagekit, I made a mistake while writing.

If it's packagekit then isn't it going to be some part of your
desktop environment? Which desktop environment are you using?

GNOME will download updates and prompt you to install. To disable this open
"GNOME software",m burger menu, "Update Preferences".

The default behaviour of GNOME Software is to only download upgrades when on an
unmetered connection so if you are using GNOME and this is what is happening,
then as Max says telling NetworkManager that your connection is metered should
stop it.

> I disable the timers, thanks

I don't think it's any of the systemd timers or unattended-upgrades.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

Max Nikulin

unread,
Feb 19, 2024, 9:30:05 PMFeb 19
to
On 20/02/2024 02:35, Erwan David wrote:
> Le 19/02/2024 à 18:00, Max Nikulin a écrit :
>>     systemctl disable --now apt-daily.timer apt-daily-upgrade.timer
>>
>> Perhaps it is possible to write a script that will respect
>> connection.metered property set by NetworkManager.
>
> I disable the timers, thanks

To avoid confusion, these timers are from the apt package, not from
unattended-upgrades. So they are active on most Debian hosts. Desktop
environments may display notifications after actions initiated by these
timers. Likely desktop environments may do more, e.g. to query GNOME
application shop for updates and initiate more frequent updates.

> I'll have a look at connection.metered

Out of curiosity I have queried https://codesearch.debian.net. It seems,
apt has no notion of metered connection. Perhaps the effect can be
achieved by adding to unit configuration some Condition* mentioned in
systemd.directives(7)

https://stackoverflow.com/questions/43228973/detect-if-current-connection-is-metered-with-networkmanager

busctl get-property \
org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager \
org.freedesktop.NetworkManager Metered

Greg Wooledge

unread,
Feb 19, 2024, 10:30:07 PMFeb 19
to
On Tue, Feb 20, 2024 at 09:20:11AM +0700, Max Nikulin wrote:
> > >     systemctl disable --now apt-daily.timer apt-daily-upgrade.timer

> To avoid confusion, these timers are from the apt package, not from
> unattended-upgrades. So they are active on most Debian hosts.

Holy crap... when did this happen?

I tried looking on salsa and it looks like the 1.8.y branch has these
files, but the jessie branch does not. But I don't know where the
"preset: enabled" thing comes from. So maybe the files were there but
not enabled by default until recently? Maybe?

Does anyone know when these things changed, and why on earth nobody
knew about it?! Did I miss a section in the release notes or something?

Andy Smith

unread,
Feb 19, 2024, 11:00:07 PMFeb 19
to
Hi,

On Mon, Feb 19, 2024 at 10:21:24PM -0500, Greg Wooledge wrote:
> Does anyone know when these things changed, and why on earth nobody
> knew about it?! Did I miss a section in the release notes or something?

Why are you shocked by this? Most of it is disabled by default (no
update / upgrade / unattended-upgrade). You have to set things like
APT::Periodic::Update-Package-Lists to 1.

It's been there since Debian 9 (stretch) IIRC.

The handbook has stuff about it.

https://debian-handbook.info/browse/stable/sect.regular-upgrades.html

Greg Wooledge

unread,
Feb 19, 2024, 11:30:06 PMFeb 19
to
On Tue, Feb 20, 2024 at 03:56:49AM +0000, Andy Smith wrote:
> On Mon, Feb 19, 2024 at 10:21:24PM -0500, Greg Wooledge wrote:
> > Does anyone know when these things changed, and why on earth nobody
> > knew about it?! Did I miss a section in the release notes or something?
>
> Why are you shocked by this? Most of it is disabled by default (no
> update / upgrade / unattended-upgrade). You have to set things like
> APT::Periodic::Update-Package-Lists to 1.
>
> It's been there since Debian 9 (stretch) IIRC.
>
> The handbook has stuff about it.
>
> https://debian-handbook.info/browse/stable/sect.regular-upgrades.html

According to this page, the configuration is in
/etc/apt/apt.conf.d/10periodic (which does not exist on my system).

Also according to this page, there is a script in
/usr/lib/apt/apt.systemd.daily which describes the configuration
variables (this script does exist).

According to the /usr/lib/apt/apt.systemd.daily script, the
/etc/apt/apt.conf.d/10periodic file has to be created if you want to
change the defaults. OK.

Also according to that script, the default values are listed in the
comments of said script.

These comments include:

# APT::Periodic::Enable "1";
# - Enable the update/upgrade script (0=disable)

which, if I'm reading this correctly, says that this thing is enabled
by default. "This thing" being an "update/upgrade script". Whatever
that means.

The comments also include:

# APT::Periodic::Update-Package-Lists "0";
# - Do "apt-get update" automatically every n-days (0=disable)
#
# APT::Periodic::Download-Upgradeable-Packages "0";
# - Do "apt-get upgrade --download-only" every n-days (0=disable)

I'm not sure how to interpret this combination of things. Do these
default settings mean "the update/upgrade script will run, but it won't
actually do anything"?

Erwan David

unread,
Feb 20, 2024, 2:50:06 AMFeb 20
to
It would also require to configure NetworkManager to set this correctly.
Eg When I use USB tethering. (same NetworkManager connexion may be used
at different places, without any way to simply detect this, when you do
not use Wifi)

--
Erwan David

Erwan David

unread,
Feb 20, 2024, 3:00:06 AMFeb 20
to
I use KDE, and I do not know wether discover does an update by itself. I
do not thind any setting about this

--
Erwan David

Michael

unread,
Feb 20, 2024, 4:30:06 AMFeb 20
to
On Tuesday, February 20, 2024 5:23:35 AM CET, Greg Wooledge wrote:
> I'm not sure how to interpret this combination of things. Do these
> default settings mean "the update/upgrade script will run, but it won't
> actually do anything"?

kind of...

lines 354-360 (on bookworm) of said script (/usr/lib/apt/apt.systemd.daily)
checks if 'APT::Periodic::Enable' is set to 1. if not, the script exits
with 0:

# check if the user really wants to do something
AutoAptEnable=1 # default is yes
eval $(apt-config shell AutoAptEnable APT::Periodic::Enable)

if [ $AutoAptEnable -eq 0 ]; then
exit 0
fi

i very much dislike the fact that my systems do things i am not aware of. i
don't mind if this timer/service exists, but i do not want it to be enabled
by default. especially if its default setting is to do nothing (useful,
critical, necessary)! why add complication to a system and waste its
resources if it defaults to not doing anything? why not add .timer and
.service, but keep it disabled by default? admin's choice...

imho it is even easier and more intuitive to enable the timer than to add a
file in which i change/set an option to prevent an already started process
to exit prematurely having already wasted system resources.

but that's just me. ymmv...

greetings...

Andy Smith

unread,
Feb 20, 2024, 6:50:05 AMFeb 20
to
Hi,

On Tue, Feb 20, 2024 at 10:17:17AM +0100, Michael wrote:
> i very much dislike the fact that my systems do things i am not aware of.

I think one of the purposes of a Linux distribution is to pull
together a collection of disparate software of their choosing and
make default decisions for their users.

I find it hard to believe that you bother to delve into the
behaviour of your system in most other ways, but suddenly you've
become aware of a systemd timer and now it's a problem for you. None
of this is hidden. You've been able to read this script and work out
how it works.

Do you also build your own kernels so you can personally sign off on
every kernel config choice, or do you trust the Debian kernel team's
ideas about what should be built in, modularised or not available at
all?

For me it's a problem when things can't be customised. I expect
default choices to be made but I don't expect to agree with 100% of
them. That's OK.

Andy Smith

unread,
Feb 20, 2024, 7:00:06 AMFeb 20
to
Hi,

On Tue, Feb 20, 2024 at 08:52:09AM +0100, Erwan David wrote:
> I use KDE, and I do not know wether discover does an update by itself. I do
> not thind any setting about this

I think it is very likely that KDE has an equivalent to GNOME, which
does the equivalent of "apt update" every day and then notifies you
about available package upgrades.

Erwan David

unread,
Feb 20, 2024, 7:40:06 AMFeb 20
to
Le 20/02/2024 à 12:46, Andy Smith a écrit :
> Hi,
>
> On Tue, Feb 20, 2024 at 08:52:09AM +0100, Erwan David wrote:
>> I use KDE, and I do not know wether discover does an update by itself. I do
>> not thind any setting about this
> I think it is very likely that KDE has an equivalent to GNOME, which
> does the equivalent of "apt update" every day and then notifies you
> about available package upgrades.
>
> Thanks,
> Andy
>
Yes, and it seems to be plasma-discover. But I do noit find how to
configure it NOT to update package list automatically.

A systemctl --user list-units '*discover*'  gives
 UNIT                                                        LOAD
  ACTIVE SUB     DESCRIPTION
 app-org.kde.discover-5f3c6a37712a431b929cbe82aa9555dc.scope loaded
active running Discover - Logithèque
 app-org.kde.di...@autostart.service             loaded
active running Discover

a list-unit-files says the service is generated. I did nit find from
what it os generated.

There is /etc/xdg/autostart/org.kde.discover.notifier.desktop


which ends in


Exec=/usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier
Icon=system-software-update
Type=Application
NoDisplay=true
X-KDE-autostart-phase=1
OnlyShowIn=KDE

DiscoverNotifier comes form the plasma-discover package

The pacakge contains a /usr/bin/plasma-discover-update binary, whose
name appears in DiscoverNotifier binary...


I'll try looking this way.


I would have preferred being able to disable it (especially because it
shows me a systray indication when there are upgradable packages) but if
it is not possible I can remove it (it won't remove the meta-packages of
the DE)

Greg Wooledge

unread,
Feb 20, 2024, 7:50:07 AMFeb 20
to
On Tue, Feb 20, 2024 at 11:39:56AM +0000, Andy Smith wrote:
> On Tue, Feb 20, 2024 at 10:17:17AM +0100, Michael wrote:
> > i very much dislike the fact that my systems do things i am not aware of.
>
> I think one of the purposes of a Linux distribution is to pull
> together a collection of disparate software of their choosing and
> make default decisions for their users.
>
> I find it hard to believe that you bother to delve into the
> behaviour of your system in most other ways, but suddenly you've
> become aware of a systemd timer and now it's a problem for you. None
> of this is hidden. You've been able to read this script and work out
> how it works.

For me, it's a combination of two things:

1) This apt-daily.timer stuff is quite complex and difficult to discover
and understand. Most subsystems have a single configuration file
that controls what they do, and it's in some place that's relatively
easy to find.

This thing has no configuration file by default; you have to read the
comments in the software itself to figure out what it does.

2) In the absence of a full understanding, it's easy to suspect that these
timers will download package lists and/or packages from the Internet.
That's what the names imply, after all.

Here's what the end user (me) sees upon first inspection:

* apt-daily.timer is enabled (by default)
* apt-daily.timer runs twice a day
* apt-daily.service has Description=Daily apt download activities
* apt-daily.service runs "/usr/lib/apt/apt-helper wait-online"
and then "/usr/lib/apt/apt.systemd.daily update"

If the end user doesn't actually read through this 538 line shell
script to analyze its behavior, this all *looks* very much like
"run apt update twice a day".

Likewise, there's a second timer:

* apt-daily-upgrade.timer is enabled (by default)
* apt-daily-upgrade.timer runs once a day
* apt-daily-upgrade.service has
Description=Daily apt upgrade and clean activities
* apt-daily-upgrade.service runs "/usr/lib/apt/apt-helper wait-online"
and then "/usr/lib/apt/apt.systemd.daily install"

As with the other timer and service, this all looks very much like it
will upgrade packages, once a day.

to...@tuxteam.de

unread,
Feb 20, 2024, 8:00:06 AMFeb 20
to
On Tue, Feb 20, 2024 at 07:44:55AM -0500, Greg Wooledge wrote:

[...]

> For me, it's a combination of two things:
>
> 1) This apt-daily.timer stuff is quite complex and difficult to discover
> and understand [...]

I gather this from the thread, yes. I just checked, and the scripts
come with apt -- but they are ineffective if one is "on" SysV init.

All is well. Phew ;-)

Cheers
--
t
signature.asc

Andy Smith

unread,
Feb 20, 2024, 9:40:07 AMFeb 20
to
Hello,

On Tue, Feb 20, 2024 at 07:44:55AM -0500, Greg Wooledge wrote:
> This thing has no configuration file by default; you have to read the
> comments in the software itself to figure out what it does.

Or, say, the Debian Administrator's Handbook.

https://www.debian.org/doc/manuals/debian-handbook/sect.regular-upgrades.en.html

The configuration options are also described in the man page for
apt.conf.

https://manpages.debian.org/bookworm/apt/apt.conf.5.en.html#PERIODIC_AND_ARCHIVES_OPTIONS

Max Nikulin

unread,
Feb 20, 2024, 9:50:06 AMFeb 20
to
On 20/02/2024 19:44, Greg Wooledge wrote:
> 1) This apt-daily.timer stuff is quite complex and difficult to discover
> and understand.

I am sorry that I confused enough people by my statements. I believed
that by default this timer runs "apt update" every day while upgrades
are not enabled out of the box. Perhaps I saw active updates on an
Ubuntu box and maybe desktop environment stuff was involved.

So the apt package just installs timers and services, but configuration
files to enable update and upgrade come from unattended-upgrades and
maybe some other packages.

Unfortunately ExecCondition is allowed only in the [Service] section, so
it is not possible to avoid starting of timers basing on result of a
helper script that queries apt configuration.

In the absence of systemd likely cron jobs may be configured (apticron?).

Max Nikulin

unread,
Feb 20, 2024, 10:00:06 AMFeb 20
to
I am unsure if the following would be convenient. You may create a
couple of connections with and without connection.metered set. Default
is metered, but when you know that currently traffic is not expensive,
you may manually switch to one marked as non-metered.
0 new messages