Open Corsaire0177 opened 2 years ago
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
Did you observe this behavior in any normal ssh sessions? Maybe aptitude on ansible does not run non-interactive.
Problem happens on debian10 (buster) with needrestart 3.4 and 3.5
After doing a apt upgrade you get the following :
There it just sits ... you can only do a ctrl+c to get out of it.
Looking at the processes it became a zombie. The faulty process :
Killing the parent process "frontend" is also a way to get out of it.