apt hook slows down apt - could this be asynchronous?
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
update-notifier (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Hi,
I was actually looking for needrestart as it has the last messages in an apt transaction and then seems to stall. But I found that it isn't
/etc/
instead it is the other 99 which is
/etc/
I've littered the steps it executes for debugging and found that the final call to `/usr/lib/
Here at the end of an `apt install --reinstall` of any package.
DEBUG I 07:04:54.330869746
DEBUG II 07:04:54.331734979
DEBUG III 07:04:54.350096999
DEBUG IV 07:04:54.360757929
DEBUG V 07:04:54.376343616
DEBUG VI 07:04:54.379049099
DEBUG VII 07:04:54.386505261
DEBUG VIII 07:04:58.824188091 <<< those 4 seconds
DEBUG IX 07:04:58.826370395
DEBUG IX 07:04:58.827825319
The time varies on system HW and installed packages, but is always at an annoying >1sec.
If not just an automated background install people often wait for apt to complete to be able to do the next steps.
And then apt seeming complete (it is actually) but having this artificial delay makes Ubuntu feel slow every time.
This is only meant to populate /var/lib/
Somewhere in the back of my mind was that this was tried ...
And what makes me suspicious is at least:
# let the actual update be asynchronous to avoid stalling apt-get
cleanup() { rm -f "$tmpfile"; }
I checked the change-log for it and found bug 1527710 which explains why - currently - it isn't asynchronous anymore. (The changelog also explains why I thought to remember this being async, I did that myself 6 years ago). I have to agree all those issues with the asynchronicity back then were bad, but while the current stall isn't as "breaking" is is really bad on the "user inconvenience" side of things.
I wanted to file this bug (despite it being tried in the past) to discuss if we could find a way to disconnect these and make apt fast again.
How about fully decoupling the hook and the check?
Like letting /usr/lib/ update- notifier/ update- motd-updates- available only do the post-apt processing if a check "is needed" and then touch a stamp or similar.
That would give apt the fast path we want to have.
Independently we could then have something that regularly checks if the stamp exists or changed - and if so run the actual "/usr/lib/ update- notifier/ apt-check --human-readable" to output to "/var/lib/ update- notifier/ updates- available" which is what motd will later consume.
I think nowadays we can do better than "check every x minutes" like thtough systemd https:/ /www.freedeskto p.org/software/ systemd/ man/systemd. path.html.
Imagine (untested suggestion) instead of writing to: lib/update- notifier/ update- motd-updates- available lib/update- notifier/ update- motd-updates- available- needcheck
/usr/
it would only write the output of `date` to:
/usr/
Then we could have: system/ update- motd-updates- available. service target
$ cat /etc/systemd/
[Unit]
Description=Update list of available updates for update-notifier
After=network.
[Service] /usr/lib/ update- notifier/ apt-check --human-readable file:/usr/ lib/update- notifier/ update- motd-updates- available
Type=oneshot
ExecStart=
StandardOutput=
$ cat /etc/systemd/ system/ update- motd-updates- available. path /usr/lib/ update- notifier/ update- motd-updates- available- needcheck
[Path]
PathModified=
[Install] multi-user. target
WantedBy=
I'd hope that this would achieve
a) apt transactions being fast
b) the info of available packages will be updated immediately
c) the old issues of 1527710 were around mount/chroot/umount and similar.
In those the service would not run -> no conflict
d) since there is no direct child process other old issues e.g. preseeding
should also not be affected anymore
Opinions?