While running “sudo apt upgrade” via SSH to update Virtualmin 8.0.1 to 8.1.0, dpkg got stuck.
First this happened at 78%.
After waiting half an hour, nothing happened.
Opening Webmin showed that it had actually updated to 8.1.0, but apparently not completely, or DPKG didn’t think it succeeded, in any case, trying another “sudo apt upgrade” via SSH to finish the other updates gives the error message
dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
But doing this starts the "Setting up webmin-virtual-server (8.1.0.gpl-1) " over again, and it again gets stuck, this time at 71%.
Webmin and Virtualmin seem to be functioning correctly, but how to fix DPKG to get it to stop trying to re-run the webmin-virtual-server (8.1.0.gpl-1) update ?
It’s getting hung during the postinstall script, I assume. Which shouldn’t happen…you may want to strace the hung process PID to see what it’s trying to do.
You might also look at the webmin-virtual-server maintainer scripts in /var/lib/dpkg/info to see if anything jumps out as being an issue on your system. If not, you could add some debug “echo” lines to the postinst script to tell you where it’s hanging and then do dpkg --configure -a and see roughly where it hangs.
I had the same problem and it showed, that my firewall is too aggressive, for this upgrade,
so I got a network failure. Maybe other users can “solve” this with a timeout for themself,
but my server (devuan6) was “endless” waiting. With a short period of time to allow traffic
since the upgrade, it was working normal. I only open webmin/usermin ports, when i am on
the server (like port-knocking), and again, if the ports are closed, this breaks the upgrade
on my machine.
That indicates a bug in our postinstall script. I assume it’s doing a config check or something else that uses our online tools for checking connectivity and such. But, a package simply isn’t allowed to do things that can hang. If an error can occur or there’s a network request that can fail, that’s going to cause problems for someone and leave the package manager in an unhappy state until it is manually corrected.
That indicates a DNS lookup is happening, which isn’t a surprise since I’m assuming the problem is a network request happening.
I’m sure Jamie knows what it’s doing in the postinstall, it just shouldn’t be happening there. If those network requests really have to happen during package installation then it can’t be possible to fail (i.e. it has to timeout in a reasonable time/fashion and exit without error), but it’d be better if network requests don’t happen at all in a package during install.
We certainly shouldn’t be doing any outgoing network requests as part of the postinstall, but I can’t guarantee we’re not doing any DNS lookups … especially for the names of hosted domains.
What are the actual IP and port in that connect call? We’d need that in order to determine what kind of network traffic is being blocked on.