Unattended Upgrades Ran Anyway.

[Charles Curley]

Due to the recent traffic about the defective kernel in Bookworm
(12.3), I shut down unattended-upgrades on all my machines (Bookworm
and Bullseye). To my surprise, three of them ran unattended-upgrades
anyway.

One of them is Bullseye, so it was a harmless error. But still….

The two Bookworm machines are recent installations, to 12.2 as
upgraded. Fortunately, in both cases the upgrade failed because someone
was smart enough to pull the plug on the defective kernel. My thanks to
that someone.

I double checked this morning. All machines had unattended upgrades
shut off as of yesterday evening, well before the unattended-uogrades
ran.

--------------------------------------------------
Date: Sun, 10 Dec 2023 04:43:10 -0700 (MST)
From: ro...@issola.localdomain
To: cha...@issola.localdomain
Subject: unattended-upgrades result for issola.localdomain: FAILURE

Unattended upgrade result: The URI http://deb.debian.org/debian/pool/m
ain/l/linux-signed-amd64/linux-image-6.1.0-14-amd64_6.1.64-1_amd64.de
b failed to download, aborting

Unattended-upgrades log:
Starting unattended upgrades script
Allowed origins are: origin=Debian,codename=bookworm-updates, origin=Debian,codename=bookworm,label=Debian,
+origin=Debian,codename=bookworm,label=Debian-Security, origin=Debian,codename=bookworm-security,label=Debian-Security
Initial blacklist:
Initial whitelist (not strict):
An error occurred: 403 Access denied - broken package [IP: 192.168.100.12 3142]
The URI http://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.1.0-14-amd64_6.1.64-1_amd64.deb failed to download,
+aborting
--------------------------------------------------
root@issola:/var# systemctl status unattended-upgrades.service
○ unattended-upgrades.service - Unattended Upgrades Shutdown
Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; preset: enabled)
Active: inactive (dead) since Sat 2023-12-09 19:06:51 MST; 13h ago
Duration: 4d 4h 4min 2.799s
Docs: man:unattended-upgrade(8)
Process: 786 ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal (code=exited, status=0/SUCCESS)
Main PID: 786 (code=exited, status=0/SUCCESS)
CPU: 87ms

Dec 05 15:02:48 issola systemd[1]: Started unattended-upgrades.service - Unattended Upgrades Shutdown.
Dec 09 19:06:51 issola systemd[1]: Stopping unattended-upgrades.service - Unattended Upgrades Shutdown...
Dec 09 19:06:51 issola systemd[1]: unattended-upgrades.service: Deactivated successfully.
Dec 09 19:06:51 issola systemd[1]: Stopped unattended-upgrades.service - Unattended Upgrades Shutdown.
[1]+ Done firewall-config
root@issola:/var#

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[Michael Kjörling]

On 10 Dec 2023 08:49 -0700, from charle...@charlescurley.com (Charles Curley):

> Due to the recent traffic about the defective kernel in Bookworm
> (12.3), I shut down unattended-upgrades on all my machines (Bookworm
> and Bullseye). To my surprise, three of them ran unattended-upgrades
> anyway.

Exactly how did you "shut down" unattended-upgrades?

--
Michael Kjörling 🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[Max Nikulin]

On 10/12/2023 22:49, Charles Curley wrote:
> root@issola:/var# systemctl status unattended-upgrades.service

systemctl status apt-daily-upgrade.timer

[Stefan Monnier]

> I double checked this morning. All machines had unattended upgrades
> shut off as of yesterday evening, well before the
> unattended-uogrades ran.

On my trusty Thinkpad X30, upgrades are sufficiently taxing that having
them run unexpectedly can be a real problem, so I tried to prevent
unattended upgrades a few months ago.

IIRC my first step was to remove the `unattended-upgrades` (which I had
manually installed many years ago, when I *did* want upgrades to be
automatic), but that did very little.

FWIW, it felt like "whack-a-mole", where there seemed to always be
another way unattended upgrades could be started :-(


Stefan

[Charles Curley]

On Sun, 10 Dec 2023 16:11:44 +0000
Michael Kjörling <2695bd...@ewoof.net> wrote:

> On 10 Dec 2023 08:49 -0700, from charle...@charlescurley.com

> (Charles Curley): [...]

>
> Exactly how did you "shut down" unattended-upgrades?
>

root@chaffee:/etc/dhcp# systemctl stop unattended-upgrades.service
root@chaffee:/etc/dhcp# systemctl status unattended-upgrades.service

● unattended-upgrades.service - Unattended Upgrades Shutdown

Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Sat 2023-12-09 19:06:51 MST; 6s ago
Docs: man:unattended-upgrade(8)
Process: 540 ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal (code=exited, status=0/SUCCESS)
Main PID: 540 (code=exited, status=0/SUCCESS)
CPU: 1.661s

Oct 09 02:02:20 chaffee systemd[1]: Started Unattended Upgrades Shutdown.
Dec 09 19:06:42 chaffee systemd[1]: Stopping Unattended Upgrades Shutdown...
Dec 09 19:06:51 chaffee systemd[1]: unattended-upgrades.service: Succeeded.
Dec 09 19:06:51 chaffee systemd[1]: Stopped Unattended Upgrades Shutdown.
Dec 09 19:06:51 chaffee systemd[1]: unattended-upgrades.service: Consumed 1.661s CPU time.
root@chaffee:/etc/dhcp#

[Charles Curley]

On Sun, 10 Dec 2023 23:59:04 +0700
Max Nikulin <mani...@gmail.com> wrote:

> On 10/12/2023 22:49, Charles Curley wrote:

> [...]
>
> systemctl status apt-daily-upgrade.timer
>

root@issola:~# systemctl status apt-daily-upgrade.timer
● apt-daily-upgrade.timer - Daily apt upgrade and clean activities
Loaded: loaded (/etc/systemd/system/apt-daily-upgrade.timer; enabled; preset: enabled)
Active: active (waiting) since Tue 2023-12-05 15:02:47 MST; 4 days ago
Trigger: Mon 2023-12-11 04:52:42 MST; 17h left
Triggers: ● apt-daily-upgrade.service

Dec 05 15:02:47 issola systemd[1]: Started apt-daily-upgrade.timer - Daily apt upgrade and clean activities.
root@issola:~#

Thank you.

[David Wright]

Why is the service loaded, enabled and enabled then? Don't you need
to disable or mask it? Presumably it sits there, dead, all day
normally, and pops up at an appropriate time.

Cheers,
David.

[Charles Curley]

On Sun, 10 Dec 2023 14:17:36 -0600
David Wright <deb...@lionunicorn.co.uk> wrote:

> Why is the service loaded, enabled and enabled then? Don't you need
> to disable or mask it? Presumably it sits there, dead, all day
> normally, and pops up at an appropriate time.

As I understand things, start and stop are for immediate changes.
enable and disable are for boot time. So the service is turned off
until I either start it up again manually or reboot the computer.

Then there's masking, which is a whole nother can of lawyers. And a
slew of other states. See Table 1. is-enabled output, in man systemctl.

[David Wright]

On Sun 10 Dec 2023 at 13:39:50 (-0700), Charles Curley wrote:
> On Sun, 10 Dec 2023 14:17:36 -0600
> David Wright <deb...@lionunicorn.co.uk> wrote:
>
> > Why is the service loaded, enabled and enabled then? Don't you need
> > to disable or mask it? Presumably it sits there, dead, all day
> > normally, and pops up at an appropriate time.
>
> As I understand things, start and stop are for immediate changes.
> enable and disable are for boot time. So the service is turned off
> until I either start it up again manually or reboot the computer.
>
> Then there's masking, which is a whole nother can of lawyers. And a
> slew of other states. See Table 1. is-enabled output, in man systemctl.

I think it might be worth googling and reading "three levels of off"
(with the quotes).

1. You can stop a service. That simply terminates the running
instance of the service and does little else. If due to some form
of activation (such as manual activation, socket activation, bus
activation, activation by system boot or activation by hardware
plug) the service is requested again afterwards it will be
started. Stopping a service is hence a very simple, temporary and
superficial operation.

Cheers,
David.

[Dan Ritter]

Stefan Monnier wrote:
> On my trusty Thinkpad X30, upgrades are sufficiently taxing that having
> them run unexpectedly can be a real problem, so I tried to prevent
> unattended upgrades a few months ago.

I have always preferred the apticron package, which by default
updates daily and sends an email letting me know that they are
available, rather than doing the upgrade itself.

-dsr-

[Charles Curley]

Thanks. I will disable as well.

[Greg Wooledge]

On Sun, Dec 10, 2023 at 02:10:43PM -0700, Charles Curley wrote:
> On Sun, 10 Dec 2023 14:51:48 -0600
> David Wright <deb...@lionunicorn.co.uk> wrote:
>
> > I think it might be worth googling and reading "three levels of off"
> > (with the quotes).
> >
> > 1. You can stop a service. That simply terminates the running
> > instance of the service and does little else. If due to some form
> > of activation (such as manual activation, socket activation, bus
> > activation, activation by system boot or activation by hardware
> > plug) the service is requested again afterwards it will be
> > started. Stopping a service is hence a very simple, temporary and
> > superficial operation.
>
> Thanks. I will disable as well.

Disable *what*? Disabling a .service unit which is triggered by a timer
event isn't going to stop it from running.

*Masking* a .service would prevent it from running when requested by a
timer event.

Apart from that, you'd have to remove the timer event. However you do
that. I've never used systemd timers yet.

[Charles Curley]

On Sun, 10 Dec 2023 17:27:39 -0500
Greg Wooledge <gr...@wooledge.org> wrote:

> >
> > Thanks. I will disable as well.
>
> Disable *what*? Disabling a .service unit which is triggered by a
> timer event isn't going to stop it from running.

Sorry. I had already stopped the apt-daily-upgrade.timer, which
triggers the unattended upgrade service. (The couldn't give them
similar names to act as a mnemonic?) This refers to disabling the
unattended upgrade service.

>
> *Masking* a .service would prevent it from running when requested by a
> timer event.
>
> Apart from that, you'd have to remove the timer event. However you do
> that. I've never used systemd timers yet.

I *think* that's got it. Now to be sure I remember all this when it
comes time to allow automatic upgrades again.

[songbird]

as everyone can have their own reasons for what they are
doing i would not expect anyone else to do what i am but
since we're on the topic. :)

i do not run auto updates of any kind for Debian (for
either testing or stable or any other instances i may
have set up). currently i don't have any oddities out
there running. instead, each morning i cold start my
computer (i prefer it being off when i am not using it)
and it boots into testing i drag in my new e-mails and
usenet group posts and then fire up the update of the
indexes for the various Debian package repositories it
needs. after the update finishes then i check to see
what kind of updates are there. some days i scan the
list and just pull it all and apply them, other days i
will hold certain packages because i don't want to deal
with it that day. i run a few packages from sid/unstable
but they usually are self-contained enough that i don't
worry about it.


songbird

[Max Nikulin]

On 11/12/2023 06:12, Charles Curley wrote:
>
> Sorry. I had already stopped the apt-daily-upgrade.timer, which
> triggers the unattended upgrade service. (The couldn't give them
> similar names to act as a mnemonic?) This refers to disabling the
> unattended upgrade service.

I have not tested it, but from unit and scripts content my impression is
that apt-daily-upgrade.service may apply security updates even when the
unattended-upgrades package is not installed. Despite
apt-daily-upgrade.timer is enabled out of the box, without
unattended-upgrades, the service does nothing in default configuration.
There are apt.conf settings to enable/diable upgrades.

As to "systemctl mask UNIT.service", the valid use case is suppressing a
service that may be activated through D-Bus. The price is noise in logs
on each attempt to invoke a D-Bus method. I am unsure if D-Bus specs
allows to hide a D-Bus .service file (do not confuse with systemd
services) installed by some package.

Usually it is enough to "systemdctl disable --now UNIT" for a .timer or
a .socket that may cause activation of the service.

I assume unit dependencies and preventing accidental start from command
line are rather specific use cases.