Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #264512 > unrolled thread

Unattended Upgrades Ran Anyway.

Back to article view | Back to linux.debian.user

Contents

  Unattended Upgrades Ran Anyway. Charles Curley <charlescurley@charlescurley.com> - 2023-12-10 17:00 +0100
    Re: Unattended Upgrades Ran Anyway. Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-12-10 17:20 +0100
      Re: Unattended Upgrades Ran Anyway. Charles Curley <charlescurley@charlescurley.com> - 2023-12-10 19:10 +0100
        Re: Unattended Upgrades Ran Anyway. David Wright <deblis@lionunicorn.co.uk> - 2023-12-10 21:20 +0100
          Re: Unattended Upgrades Ran Anyway. Charles Curley <charlescurley@charlescurley.com> - 2023-12-10 21:50 +0100
            Re: Unattended Upgrades Ran Anyway. David Wright <deblis@lionunicorn.co.uk> - 2023-12-10 22:00 +0100
              Re: Unattended Upgrades Ran Anyway. Charles Curley <charlescurley@charlescurley.com> - 2023-12-10 22:20 +0100
                Re: Unattended Upgrades Ran Anyway. Greg Wooledge <greg@wooledge.org> - 2023-12-10 23:30 +0100
                  Re: Unattended Upgrades Ran Anyway. Charles Curley <charlescurley@charlescurley.com> - 2023-12-11 00:20 +0100
                    Re: Unattended Upgrades Ran Anyway. Max Nikulin <manikulin@gmail.com> - 2023-12-11 03:50 +0100
    Re: Unattended Upgrades Ran Anyway. Max Nikulin <manikulin@gmail.com> - 2023-12-10 18:00 +0100
      Re: Unattended Upgrades Ran Anyway. Charles Curley <charlescurley@charlescurley.com> - 2023-12-10 19:20 +0100
    Re: Unattended Upgrades Ran Anyway. Stefan Monnier <monnier@iro.umontreal.ca> - 2023-12-10 18:30 +0100
      Re: Unattended Upgrades Ran Anyway. Dan Ritter <dsr@randomstring.org> - 2023-12-10 22:10 +0100
        Re: Unattended Upgrades Ran Anyway. songbird <songbird@anthive.com> - 2023-12-11 02:20 +0100

#264512 — Unattended Upgrades Ran Anyway.

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: root@issola.localdomain
To: charles@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/

[toc] | [next] | [standalone]

#264518

On 10 Dec 2023 08:49 -0700, from charlescurley@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?”

[toc] | [prev] | [next] | [standalone]

#264543

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

> On 10 Dec 2023 08:49 -0700, from charlescurley@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# 


-- 
Does anybody read signatures any more?

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

[toc] | [prev] | [next] | [standalone]

#264557

On Sun 10 Dec 2023 at 11:00:37 (-0700), Charles Curley wrote:
> On Sun, 10 Dec 2023 16:11:44 +0000
> Michael Kjörling <2695bd53d63c@ewoof.net> wrote:
> 
> > On 10 Dec 2023 08:49 -0700, from charlescurley@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#

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.

[toc] | [prev] | [next] | [standalone]

#264559

On Sun, 10 Dec 2023 14:17:36 -0600
David Wright <deblis@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.

-- 
Does anybody read signatures any more?

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

[toc] | [prev] | [next] | [standalone]

#264561

On Sun 10 Dec 2023 at 13:39:50 (-0700), Charles Curley wrote:
> On Sun, 10 Dec 2023 14:17:36 -0600
> David Wright <deblis@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.

[toc] | [prev] | [next] | [standalone]

#264563

On Sun, 10 Dec 2023 14:51:48 -0600
David Wright <deblis@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.

-- 
Does anybody read signatures any more?

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

[toc] | [prev] | [next] | [standalone]

#264566

On Sun, Dec 10, 2023 at 02:10:43PM -0700, Charles Curley wrote:
> On Sun, 10 Dec 2023 14:51:48 -0600
> David Wright <deblis@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.

[toc] | [prev] | [next] | [standalone]

#264569

On Sun, 10 Dec 2023 17:27:39 -0500
Greg Wooledge <greg@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.

-- 
Does anybody read signatures any more?

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

[toc] | [prev] | [next] | [standalone]

#264578

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.

[toc] | [prev] | [next] | [standalone]

#264530

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

systemctl status apt-daily-upgrade.timer

[toc] | [prev] | [next] | [standalone]

#264544

On Sun, 10 Dec 2023 23:59:04 +0700
Max Nikulin <manikulin@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.

-- 
Does anybody read signatures any more?

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

[toc] | [prev] | [next] | [standalone]

#264536

> 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

[toc] | [prev] | [next] | [standalone]

#264562

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-

[toc] | [prev] | [next] | [standalone]

#264573

Dan Ritter wrote:
> 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.

  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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web