- Package:
- needrestart
- Source:
- needrestart
- Submitter:
- Axel Beckert
- Date:
- 2022-05-12 08:24:03 UTC
- Severity:
- important
- Tags:
Dear Maintainer, after this evening's package upgraee run, needrestart did no more exit when running during the apt hook. htop shows a needrestart zombie process: 5803 root 20 0 25776 4224 2092 S 0.0 0.0 4:40.53 `- SCREEN -RdU 8398 root 20 0 20408 3432 2800 S 0.0 0.0 0:00.10 | `- /bin/bash 6327 root 20 0 20420 3460 2812 S 0.0 0.0 0:00.18 | `- /bin/bash 6304 root 20 0 20408 3416 2780 S 0.0 0.0 0:00.10 | `- /bin/bash 27888 root 20 0 25576 6124 2696 R 0.7 0.0 0:09.58 | | `- htop 5804 root 20 0 20404 3456 2824 S 0.0 0.0 0:00.28 | `- /bin/bash 12196 root 20 0 598M 189M 45008 S 0.0 0.3 0:08.04 | `- aptitude -u 24022 root 20 0 598M 146M 1056 S 0.0 0.2 0:00.00 | `- aptitude -u 24160 root 20 0 4308 800 716 S 0.0 0.0 0:00.00 | | `- sh -c test -x /usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true 24161 root 20 0 60748 17904 4172 S 0.0 0.0 0:00.14 | | `- /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/needrestart 24169 root 20 0 0 0 0 Z 0.0 0.0 0:00.32 | | `- needrestart 12950 root 20 0 598M 189M 45008 S 0.0 0.3 0:00.03 | `- aptitude -u
Hi Axel, could you please provide your needrestart config (if changed from defaults)? Is the problem reproducable? Could you attach strace to needrestart while it hangs? TIA & HTH, Thomas
Hi Axel, could you please provide your needrestart config (if changed from defaults)? Is the problem reproducable? Could you attach strace to needrestart while it hangs? TIA & HTH, Thomas
Hi Thomas,
Thomas Liske wrote:
"debsums -ce needrestart" says no, so no file shipped by the package
is modifed.
I also checked /etc/needrestart/*.d for additional files, but except
backup files, there seems nothing changed:
This is from one of my previous bug reports and I'm now using the
packaged file again:
it's not.)
# strace -p 24169
strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
#
And actually needrestart did all its output:
Scanning processes...
Scanning candidates...
Scanning linux images...
Running kernel seems to be up-to-date.
Restarting services...
Package configuration
┌────┤ Daemons using outdated libraries ├─────┐
│ │
│ │
│ Which services should be restarted? │
│ │
│ [*] acpid │
│ [*] atd │
│ [*] cgmanager │
│ [*] cgproxy │
│ [*] clamav-freshclam │
│ [*] cronie │
│ [ ] dbus │
│ [*] dnssec-triggerd │
│ [*] fail2ban │
│ [*] gpm │
│ [*] kerneloops │
│ [*] lvm2-lvmetad │
│ [*] lvm2-lvmpolld │
│ [*] lxcfs │
│ [*] mdadm │
│ [*] mdadm-waitidle │
│ [*] mpd │
│ [*] ntp │
│ [*] openbsd-inetd │
│ [*] postfix │
│ [*] quasselcore │
│ [*] robustirc-bridge │
│ [*] rollerd │
│ [*] rsyslog │
│ [*] spacenavd │
│ [*] ssh │
│ [*] tor │
│ [*] unbound │
│ [*] uptimed │
│ [ ] wdm │
│ │
│ │
│ <Ok> <Cancel> │
│ │
└─────────────────────────────────────────────┘
service acpid restart
service atd restart
service cgmanager restart
service cgproxy restart
service clamav-freshclam restart
service cronie restart
service dnssec-triggerd restart
service fail2ban restart
service gpm restart
service kerneloops restart
service lvm2-lvmetad restart
service lvm2-lvmpolld restart
service lxcfs restart
service mdadm restart
service mdadm-waitidle restart
service mpd restart
service ntp restart
service openbsd-inetd restart
service postfix restart
service quasselcore restart
service robustirc-bridge restart
start-stop-daemon: unable to stat //robustirc-bridge (No such file or directory)
service rollerd restart
service rsyslog restart
service spacenavd restart
service ssh restart
service tor restart
service unbound restart
service uptimed restart
Services being skipped:
service dbus restart
service wdm restart
No containers need to be restarted.
User sessions running outdated binaries:
abe @ /dev/pts/0: emacs[19225], iceweasel[5134], liferea[5241], zsh[4193]
abe @ /dev/pts/1: zsh[3134]
abe @ /dev/pts/10: zsh[17212]
abe @ /dev/pts/11: zsh[9274]
abe @ /dev/pts/12: zsh[15317]
abe @ /dev/pts/13: autossh[5455], ssh[5466], zsh[20256]
abe @ /dev/pts/14: zsh[23167]
abe @ /dev/pts/15: i3lock[6471,6472], zsh[30281]
abe @ /dev/pts/17: zsh[9316]
abe @ /dev/pts/19: less[925,6359,28543,29138], mupdf-x11[30942,31981], zsh[936]
abe @ /dev/pts/2: zsh[4359]
abe @ /dev/pts/20: zsh[15549]
abe @ /dev/pts/21: zsh[13705]
abe @ /dev/pts/22: zsh[10010]
abe @ /dev/pts/24: zsh[29046]
abe @ /dev/pts/25: zsh[12477]
abe @ /dev/pts/27: zsh[8130]
abe @ /dev/pts/3: ccze[6818], tail[6817], zsh[5301]
abe @ /dev/pts/30: zsh[5510]
abe @ /dev/pts/31: zsh[14587]
abe @ /dev/pts/34: zsh[19960]
abe @ /dev/pts/35: zsh[30555]
abe @ /dev/pts/36: zsh[21324]
abe @ /dev/pts/37: mupdf-x11[2413], zsh[1782]
abe @ /dev/pts/4: autossh[7277], ccze[7278], somethings.sh[7270], ssh[13024], zsh[5327]
abe @ /dev/pts/5: zsh[5391]
abe @ /dev/pts/8: zsh[7305]
abe @ /dev/pts/9: zsh[7331]
Debian-console-log @ /dev/pts/28: less[12665]
Debian-console-log @ /dev/pts/29: less[12682]
Debian-console-log @ /dev/tty8: daemon[12677]
Debian-console-log @ /dev/tty9: daemon[12662]
root @ /dev/pts/23: bash[6327]
root @ /dev/pts/26: bash[8398]
root @ /dev/pts/33: screen[12118]
root @ /dev/pts/5: bash[5785]
root @ /dev/pts/6: aptitude[12196,24022], bash[5804]
Message from abe@c6 on (none) at 21:50 ...
Your session is running obsolete binaries or libraries as listed below.
Please consider a relogin or restart of the affected processes!
1 aptitude[12196,24022], bash[5804]
EOF
root @ /dev/pts/7: bash[6304]
root @ /dev/tty1: getty[3793]
root @ /dev/tty2: getty[3794]
root @ /dev/tty3: getty[3795]
root @ /dev/tty4: getty[3796]
root @ /dev/tty5: getty[3797]
root @ /dev/tty6: getty[3798]
root @ /dev/tty7: Xorg[2825]
[This is where things started hanging]
So this actually might be a debconf issue, since zombies are usually
not an issue of the program which became a zombie, but of the parent
process:
stracing the debconf/frontend process yields that it's waiting for
input:
# strace -p 24161
strace: Process 24161 attached
read(9,
But pressing Enter in the hanging shell doesn't change anything and
the strace doesn't make any output either while pressing Enter.
I also checked the currently open bug reports against debconf. Quite a
few mention hanging, but none mentions zombies.
Then again, debconf hasn't seen an upload for weeks. which-pkg-broke
doesn't show many potential culprits either, given that it worked fine
on 31st of May:
dpkg Mon May 9 13:14:33 2016
tar Wed May 18 16:31:56 2016
libselinux1:amd64 Wed May 18 16:32:20 2016
needrestart Wed May 18 16:33:04 2016
gcc-6-base:amd64 Fri May 20 13:14:03 2016
libgcc1:amd64 Fri May 20 13:14:04 2016
install-info Tue May 24 12:46:02 2016
libc6:amd64 Wed Jun 1 19:47:59 2016
multiarch-support Wed Jun 1 19:48:59 2016
But the changelog.Debian.gz of libc6 doesn't seem to contain much
which could cause such an issue...
Which brings us back to this question:
Nope. Neither with calling needrestart from the commandline nor when
being called at the end of an aptitude session. :-(
Feel free to downgrade the severity. Unless someone else can confirm
this issue, I can probably consider it bad luck.
Regards, Axel
Hi Thomas, Thomas Liske wrote: I've got a new (partial) answer on that: It seems non-deterministic. I'd say it happend in about 5-10% of the cases in the past few days (i.e. 2 times within a week or so). Regards, Axel
Hi Thomas, Thomas Liske wrote: Got worse again. Had it on three different architectures (amd64, i386 and armhf) yesterday and at least on amd64 (where initially found and reported) again today. It looks different thoug today: 26243 root 20 0 538M 141M 704 S 0.0 0.2 0:00.01 | | | `- aptitude -u 26404 root 20 0 4304 744 664 S 0.0 0.0 0:00.00 | | | | `- sh -c test -x /usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pin 26405 root 20 0 60732 17968 4276 S 0.0 0.0 0:00.13 | | | | `- /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/needrestart 27204 root 20 0 19544 2824 2288 S 0.0 0.0 0:00.00 | | | | `- whiptail --backtitle Package configuration --title Pending kernel upgrad 26413 root 20 0 54524 17880 4128 S 0.0 0.0 0:00.31 | | | | `- /usr/bin/perl /usr/sbin/needrestart 27198 root 20 0 0 0 0 Z 0.0 0.0 0:00.00 | | | | `- 10-dpkg So this time another child is a zombie. Attaching to 26413 with strace just shows the following: # strace -p 26413 strace: Process 26413 attached read(0, I interpret this as waiting for input on STDIN. But from which program? I'll try get more details later with https://metacpan.org/pod/Enbugger (not yet packaged). Regards, Axel
Hi Thomas, Axel Beckert wrote: Nah, that was a false positive. It was just taking quite long and that was a dialog waiting for input. Nevertheless it still hung at the end: 26243 root 20 0 538M 141M 704 S 0.0 0.2 0:00.01 | | | `- aptitude -u 26404 root 20 0 4304 744 664 S 0.0 0.0 0:00.00 | | | | `- sh -c test -x /usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvok 26405 root 20 0 60864 18140 4276 S 0.0 0.0 0:00.14 | | | | `- /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/needrestart 26413 root 20 0 0 0 0 Z 0.0 0.0 0:00.39 | | | | `- /usr/bin/perl /usr/sbin/needrestart So it's actually debconf which fails to end needrestart cleanly as it did in my initial bug report. stracing debconf/frontend shows that it seems to wait for input on file descriptor 9: # strace -p 26405 strace: Process 26405 attached read(9, According to /proc/26405/fd/9 that's a pipe: lr-x------ 1 root root 64 Aug 16 20:41 /proc/26405/fd/9 -> pipe:[54970896] Looking for the other end of that pipe, it seems to be this process: l-wx------ 1 root root 64 Aug 16 20:41 /proc/32724/fd/1 -> pipe:[54970896] which belongs to this process: root 32724 0.0 0.0 47040 2496 ? S 20:26 0:00 /usr/sbin/consolation Stopping the consolation service already sufficed to fix the hanging debconf and the needrestart zombie, at least in this case. Now the question is, where is the bug hidden? * Why does consolation influence debconf? Or does it influence needrestart? * Could it be relevant, that needrestart/debconf ran inside a screen session? * Could it be relevant, that I have gpm or consolelog installed, too? But then again, that bug hit me the first time when consolation wasn't yet in Debian at all. So just a coincidence? Regards, Axel
tags 826044 unreproducible thanks Hi Axel, Axel Beckert <abe@debian.org> writes: good question. Could you check if needrestart has open pipes, too? Since it was still to running (not beeing a zombie, wasn't it?) there should be a pipe on STDOUT (and debconf on the other side). I don't think that screen could be the issue. From time to time I'm upgrading more than hundret (Debian) machines having needrestart installed using apt-dater (screen in the past, now tmux). I always use xterm(+tmux+ssh) - never tried consolation nor I'm using gpm (used it decades ago). I've tagged this bug as unreproducible since I'm unable to trigger it and nobody else reported a simular problem. Hopefully we can locate the issue, soon. Regards, Thomas
I'm also affected by this bug. I did not modify config either.
In my case, I have no consolation installed. And the problem seems reproducible.
32693 32695 32695 32695 pts/8 14466 Ss 0 0:00 \_ -bash
32695 14466 14466 32695 pts/8 14466 S+ 0 0:00 \_ dpkg --configure -a
14466 14467 14466 32695 pts/8 14466 S+ 0 0:00 \_ sh -c (test -x /usr/lib/needrestart/dpkg-status && /usr/lib/needrestart/dpkg-status || cat > /dev/null)
14467 14468 14466 32695 pts/8 14466 S+ 0 0:00 | \_ sh -c (test -x /usr/lib/needrestart/dpkg-status && /usr/lib/needrestart/dpkg-status || cat > /dev/null)
14468 14469 14466 32695 pts/8 14466 S+ 0 0:00 | \_ /bin/sh /usr/lib/needrestart/dpkg-status
14466 14485 14466 32695 pts/8 14466 S+ 0 0:00 \_ /bin/sh -e /var/lib/dpkg/info/linux-image-4.7.0-0.bpo.1-amd64-unsigned.postinst configure
14485 14498 14466 32695 pts/8 14466 S+ 0 0:00 \_ run-parts --report --exit-on-error --arg=4.7.0-0.bpo.1-amd64 --arg=/boot/vmlinuz-4.7.0-0.bpo.1-amd64 /etc/kernel/postinst.d
14498 14540 14466 32695 pts/8 14466 S+ 0 0:00 \_ /bin/sh -e /etc/kernel/postinst.d/initramfs-tools 4.7.0-0.bpo.1-amd64 /boot/vmlinuz-4.7.0-0.bpo.1-amd64
14540 14542 14466 32695 pts/8 14466 S+ 0 0:00 \_ /bin/sh /usr/sbin/update-initramfs -c -t -k 4.7.0-0.bpo.1-amd64 -b /boot
14542 18026 14466 32695 pts/8 14466 D+ 0 0:00 \_ sync
1 7007 6968 6968 ? -1 S 0 0:00 /bin/sh /var/lib/dpkg/info/initramfs-tools.postinst triggered update-initramfs
7007 7008 6968 6968 ? -1 S 0 0:00 \_ /bin/sh /usr/sbin/update-initramfs -u
7008 10548 6968 6968 ? -1 D 0 0:00 \_ sync
OK, it seems like I had an issue with "btrfs scrub", which didn't want to stop. After rebooting upgrade seems to work without problem, so I does not seem to be related with needrestart. Sorry for the noise...
Hi, It seems I have another instance of this issue: piuparts hangs (as I understand it) during cleanup after an initial install of design-desktop which pulls in ńeedrestart. Discussion starting at http://lists.alioth.debian.org/pipermail/piuparts-devel/2017-January/006734.html has more details - an interesting part is this extracted when piuparts hangs: 30803 root 30 10 117M 63804 9816 T 0.0 0.2 0:11.84 │ │ └─ /usr/bin/python /srv/piuparts/sbin/piuparts --skip-logrotatefiles-test --warn-on-others --no-eatmydata --scriptsdir /etc/piuparts/script 29515 root 30 10 84340 46992 32864 T 0.0 0.1 0:00.67 │ │ └─ apt-get -y install design-desktop=3.0.4 30238 root 30 10 84340 14128 0 T 0.0 0.0 0:00.00 │ │ └─ apt-get -y install design-desktop=3.0.4 30240 root 30 10 4288 752 676 T 0.0 0.0 0:00.00 │ │ └─ sh -c test -x /usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true 30241 root 30 10 55276 14444 4324 T 0.0 0.0 0:00.23 │ │ └─ /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/needrestart 30331 root 30 10 50124 17516 4148 T 0.0 0.1 0:00.40 │ │ └─ /usr/bin/perl /usr/sbin/needrestart 2846 root 30 10 4288 740 668 T 0.0 0.0 0:00.00 │ │ ├─ sh -c resize 2>/dev/null 2847 root 30 10 4188 704 632 T 0.0 0.0 0:00.00 │ │ │ └─ resize 2838 root 30 10 0 0 0 Z 0.0 0.0 0:00.00 │ │ └─ 90-none - Jonas
unblock 850948 with 826044 unmerge 826044 severity 826044 important thanks Hi, Jonas Smedegaard <dr@jones.dk> writes: piuparts does not use consolation, doesn't it? Please stop abusing this issue focusing on needrestart vs. consolation for another issue. Maybe it is just a debconf frontend issue? In cases needrestart does seems to hang it trackes down to: - daemons hangig while restarting them (init scripts) - the debconf pipe gets weirrd (consolation) - needrestart and debconf thinks you call them interactive... but they are called non-interactive. As a result they wait forever for interaction. Feel free to open a new bug to needrestart to track down this issue. Thanks, Thomas
Quoting Thomas Liske (2017-01-13 23:25:39) I fully agree, which is why I wrote "seems", and then filed a separate bugreport. Sorry, I don't know the details of piuparts the tool nor piupart.debian.net the service. That's why my separate bugreport was filed against either of needrestart or piuparts. Agreed. This would imply that either piuparts fail to setup policy-rc.d appropriately, or that needrestart ignores policy-rc.d. The latter is a Policy violation. I suspect this to be irrelevant in scenarios involving policy-rc.d. Agreed. From my brief conversations with the piuparts developers I am of the impression that piuparts a) makes use of policy-rc.d and b) tells debconf that interaction is non-interactive, c) has a quite big track record to support a) and b), d) have rarely if ever tested needrestart being pulled in as a dependency due to very few packages depending on it at all. Therefore I suggest to double-check and/or share your opinion here on whether needrestart respects policy-rc.d and doesn't do funny things with debconf. Thanks for the suggestion. I am not familiar with piupart I will likely not do so, but welcome others to pick up where I left. - Jonas
After any upgrade, needrestart hangs, with a zombie child: /-------- | root 929 27669 0 20:31 pts/2 00:00:00 aptitude install | root 930 929 0 20:31 pts/2 00:00:00 sh -c test -x /usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true | root 931 930 0 20:31 pts/2 00:00:00 /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/needrestart | root 939 931 0 20:31 pts/2 00:00:00 [needrestart] <defunct> \-------- If I kill the perl process (931 above) my package upgrade completes successfully. It looks like it's not waiting properly for its children.
Problem still exists in debian 10 After installing needrestart and doing a apt upgrade you get the following : [...] Setting up libirs161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u7) ... Setting up bind9-host (1:9.11.5.P4+dfsg-5.1+deb10u7) ... Setting up dnsutils (1:9.11.5.P4+dfsg-5.1+deb10u7) ... Processing triggers for libc-bin (2.28-10+deb10u1) ... Processing triggers for mime-support (3.62) ... Scanning processes... Scanning candidates... Failed to check for processor microcode upgrades. Restarting services... invoke-rc.d cron restart invoke-rc.d nagios-nrpe-server restart invoke-rc.d nullmailer restart invoke-rc.d open-vm-tools restart invoke-rc.d openntpd restart invoke-rc.d snmpd restart invoke-rc.d ssh restart invoke-rc.d syslog-ng restart invoke-rc.d ulogd2 restart invoke-rc.d unbound restart No containers need to be restarted. User sessions running outdated binaries: root @ /dev/pts/0: bash[10397] Message from root@kddns-sv03-stage on (none) at 18:09 ... Your session is running obsolete binaries or libraries as listed below. Please consider a relogin or restart of the affected processes! 1 bash[10397] EOF root @ /dev/tty1: getty[2053] root @ /dev/tty2: getty[2054] root @ /dev/tty3: getty[2055] root @ /dev/tty4: getty[2056] root @ /dev/tty5: getty[2057] root @ /dev/tty6: getty[2058] There it sits ad-vitam... you can only do a ctrl+c to get out of it. The faulty process : ├─sshd,10395 │ └─bash,10397 │ └─apt-get,10865 upgrade -y │ └─apt-get,12265 upgrade -y │ └─sh,12266 -c test -x /usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true │ └─frontend,12267 -w /usr/share/debconf/frontend /usr/sbin/needrestart │ └─(needrestart,12277) As you can expect this is a problem for automation or running a Ansible playbook ... kinda defeats the purpose of a non-interactive action, not to mention the fact that it shouldn't happen in the first place.
Tried to install debian11 needrestart-3.5 package, no problem regarding
dependencies, but problem still the same.
├─sshd,13265
│ └─sh,14854 -c /usr/bin/python
/root/.ansible/tmp/ansible-tmp-1650508029.18-25277-93685447926498/AnsiballZ_apt.py
&& sleep 0
│ └─python,14855
/root/.ansible/tmp/ansible-tmp-1650508029.18-25277-93685447926498/AnsiballZ_apt.py
│ └─aptitude,15365 -y -o Dpkg::Options::=--force-confdef -o
Dpkg::Options::=--force-confold safe-upgrade
│ ├─aptitude,21577 -y -o
Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold
safe-upgrade
│ │ └─sh,21578 -c test -x
/usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true
│ │ └─frontend,21579 -w
/usr/share/debconf/frontend /usr/sbin/needrestart
│ │ └─(needrestart,21583)
│ └─{aptitude},15381
needrestart,21583 gets zombie-fied
We can move on if we kill the parent process frontend,21579
Poking around I found this, could there be a relationship ?
├─sshd,14441
│ └─sh,14736 -c /usr/bin/python
/root/.ansible/tmp/ansible-tmp-1650945060.61-15873-131215080055549/AnsiballZ_apt.py
&& sleep 0
│ └─python,14737
/root/.ansible/tmp/ansible-tmp-1650945060.61-15873-131215080055549/AnsiballZ_apt.py
│ └─aptitude,15251 -y -o Dpkg::Options::=--force-confdef -o
Dpkg::Options::=--force-confold safe-upgrade
│ ├─aptitude,21329 -y -o
Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold
safe-upgrade
│ │ └─sh,21330 -c test -x
/usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true
│ │ └─frontend,21331 -w
/usr/share/debconf/frontend /usr/sbin/needrestart
│ │ └─(needrestart,21335)
│ └─{aptitude},15256
# /usr/sbin/needrestart
debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by
another process: Resource temporarily unavailable
# lsof /var/cache/debconf/config.dat
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
frontend 21331 root 4uW REG 254,2 31187 131278
/var/cache/debconf/config.dat
A needrestart process is spawned but due to
/var/cache/debconf/config.dat locked by frontend it is unable to process.
Of course may be unrelated.
Ho great...
Found out that there's the same trouble on some debian9 hosts.
I say some because not all servers did the blockage.
# cat /etc/debian_version
9.13
# dpkg -l | grep needrestart
ii needrestart 2.11-3+deb9u1 all check
which daemons need to be restarted after library upgrades
├─sshd,2094
│ ├─sshd,24499
│ │ └─sh,24594 -c /usr/bin/python
/root/.ansible/tmp/ansible-tmp-1652172426.49-4195-68636559789086/AnsiballZ_apt.py
&& sleep 0
│ │ └─python,24595
/root/.ansible/tmp/ansible-tmp-1652172426.49-4195-68636559789086/AnsiballZ_apt.py
│ │ └─aptitude,24910 -y -o
Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold
safe-upgrade
│ │ ├─aptitude,30264 -y -o
Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold
safe-upgrade
│ │ │ └─sh,30265 -c test -x
/usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true
│ │ │ └─needrestart,30266 /usr/sbin/needrestart
│ │ │ └─(10-dpkg,30299)
│ │ └─{aptitude},24914
Hi, you are using some ansible deployment? Could you share your ansible role? This is a long-standing bug and it feels like that affected users are using aptitude. I wonder if this is related - could you give it a try (force_apt_get task parameter)? Regards, Thomas
On Wed, 11 May 2022 22:59:41 +0200 Thomas Liske <thomas@fiasko-nw.net> wrote: > Hi, > > you are using some ansible deployment? Could you share your ansible > role? > > This is a long-standing bug and it feels like that affected users are > using aptitude. I wonder if this is related - could you give it a try > (force_apt_get task parameter)? Yes, using Ansible. There's nothing special in it. - name: Debian | Ensure Debian upgraded apt: update_cache: yes upgrade: "yes" tags: - os_force_upgrade