2

There are a gazillion threads about disabling unattended-upgrades. I know about them.

My beef is that the user experience with unattended-upgrade leaves a lot to be desired. An item in the task-bar thingy (top right-hand corner of xubuntu) would be the place to put a "unattended-upgrade is running. 47% done. Press here to stop it this one time" widget. I'm guessing that doesn't exist.

I have an old, low-powered laptop that I use infrequently, and when I boot it, most times it slows to a crawl for up to 15 minutes after boot because of unattended-upgrade.

So once in a while I'd like to stop it. ps -ef | grep -v grep | grep unattended-upgrade shows a PID that seems to ignore kill signals, so that is not the way to go. It also sounds dangerous just to kill apt and dpkg.

So: Is there a way to safely stop an already-started unattended-upgrade? Or are my only options:

  • Disable unattended-upgrade and be done with it. Live with the insecurity of a system that probably never gets updated.
  • Wait up to 15 minutes after boot to try out: apt-get install new-shiny-tool?
3

Yes, yes you can. Actually you can conform it to behave exactly as you would like, but please elaborate on:

So once in a while I'd like to stop it. ps -ef | grep -v grep | grep unattended-upgrade shows a PID that seems to ignore kill signals

because this part worries me a little, as it is not possible for a SIGKILL, fired as root, to be ignored by any process other than PID 1 (init) UNLESS there is a system call being processed, which if killed mid-sentence would lead to kernel code corruption. This situation does not block the SIGKILL alltogether, but turns it into an asynchroneous signal that gets delivered the moment the system call gets woken up and finishes.

Stopping

As far as unattended-upgrade , you can configure when you would like to have it start, and as far as stopping it, you should have a service :

sudo service unattended-upgrades status

Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-08-30 20:48:27 EDT; 18h ago
     Docs: man:unattended-upgrade(8)
 Main PID: 1410 (unattended-upgr)
    Tasks: 2 (limit: 4915)
   Memory: 21.9M
   CGroup: /system.slice/unattended-upgrades.service
           └─1410 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal

Aug 30 20:48:27 OPTIMUM systemd[1]: Started Unattended Upgrades Shutdown.

and

sudo service unattended-upgrades stop sudo service unattended-upgrades status

● unattended-upgrades.service - Unattended Upgrades Shutdown
   Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Sat 2019-08-31 15:44:18 EDT; 1s ago
     Docs: man:unattended-upgrade(8)
  Process: 1410 ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal (code=exited, status=0/SUCCESS)
 Main PID: 1410 (code=exited, status=0/SUCCESS)

Aug 30 20:48:27 OPTIMUM systemd[1]: Started Unattended Upgrades Shutdown.
Aug 31 15:44:18 OPTIMUM systemd[1]: Stopping Unattended Upgrades Shutdown...
Aug 31 15:44:18 OPTIMUM systemd[1]: unattended-upgrades.service: Succeeded.
Aug 31 15:44:18 OPTIMUM systemd[1]: Stopped Unattended Upgrades Shutdown.

will kill it, without having to resort to ps and pid lookup.

Delay

However, since you mentioned that the boot delay due to unattended-upgrades is another issue, you might also like to prevent this service from running directly at boot. In that case you can delay it by creating a timer for it. In order to create a timer for unattended-upgrades.service create an unattended-upgrades.timer in the same directory with the following configuration for a 5 minute boot delay:

[Unit]
Description=Run delayed

[Timer]
OnBootSec=5min

[Install]
WantedBy=timers.target

Next, disable the service and enable the timer instead to control it.

     sudo systemctl disable unattended-upgrades.service
     sudo systemctl enable unattended-upgrades.timer
     sudo systemctl start unattended-upgrades.timer
     sudo systemctl list-timers

Even if you have the timer running, you will still be able to kill the unattended-upgrades.service, but it will notify you of the timer in the background.

sudo service unattended-upgrades stop
   Warning: Stopping unattended-upgrades.service, but it can still be activated 
   by:   unattended-upgrades.timer

Widget

1
  • 1
    Super, thanks! I didn't think of just stopping it with standard systemctl. What I meant by "seems to ignore kill signals" was that kill $pid is ignored, so a SIGTERM. I'm pretty sure a SIGINT would not get ignored, but would leave dpkg/apt in a bad state, so I didn't even try that. Sep 7 '19 at 7:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.