51

So, I was performing an Ubuntu Server upgrade from 11.04 to 11.10.

I forgot about it in the background, and my SSH client timed out and disconnected (putty on Windows, go figure). The last thing on my terminal was a question about keeping an old config, etc.

When I logged back in to the server, aptitude files were locked by another process, so I assume this upgrade process is sat there waiting for my input.

How I can interact with this process and continue the upgrade? If possible.

Thanks

Stephen Melrose
  • 5,565
  • 5
  • 24
  • 21
  • 1
    possible duplicate of [Reconnect ssh session when disconnected without screen](http://serverfault.com/questions/295986/reconnect-ssh-session-when-disconnected-without-screen) – quanta Oct 14 '11 at 15:53

3 Answers3

52

The process actually runs in a screen or byobu session as the root user. reconnect to the server with putty on port 22 or the failsafe 1022. sudo su - or su - into your root account and resume the screen with byobu or a screen -r and resume where you left.

oh and yes i found out the hard way ;-)

user120896
  • 536
  • 5
  • 2
  • 1
    Woah thanks! I was actually running a release upgrade from 11.10 to 12.04 in byobu and then it closed when byobu was upgraded but I was able to reconnect to the root screen session and watch the upgrade finish! I nearly tried to forcefully kill the upgrade but luckily I read this response in time. – Ibrahim Jan 13 '13 at 09:32
  • 3
    On a stalled install, it said the screen was already attached, so I force the screen detach, the I could reattach. The command is screen -D Information from here: http://kb.iu.edu/data/ahrm.html – David Jun 07 '13 at 16:25
  • 2
    Using `screen -r ` also works, and you only need to type a few characters of the ID for it to work. – Daniel May 27 '14 at 19:37
  • 2
    This doesn't work for me, as it says that `screen` is not installed. – starbeamrainbowlabs May 14 '16 at 10:53
  • 4
    Newer Ubuntu use `sudo screen -D -r` after `sudo su -` (if not root). – B. Shea Apr 21 '17 at 02:26
  • 1
    `screen -r` worked for me on 18.04 LTS upgrading to 20.04 LTS. Thank you for this answer and thank you to whatever developer decided to run this in screen. – Tyrel Jan 14 '21 at 22:04
  • I didn't have `screen` on Debian - Teddy's answer worked: https://serverfault.com/a/321523/247083 – jave.web Feb 20 '21 at 19:09
50

You can't. Find the upgrade process by doing

lsof /var/lib/dpkg/lock

Kill it, fix any interrupted upgrades with

dpkg --configure --pending

and restart the upgrade.

Teddy
  • 5,134
  • 1
  • 22
  • 27
  • 3
    Is this safe with the process being a `do-release-upgrade`? – Stephen Melrose Oct 14 '11 at 16:02
  • 2
    @StephenMelrose It is never safe. But it is *reasonably* safe, and the only remaining option. – Teddy Jan 28 '14 at 10:53
  • 3
    best answer between many on how to fix an apt-get upgrade aborted by putty session timeout... successfully tested, thank you ! – Kojo Jan 13 '15 at 16:22
  • The `and restart the upgrade` step not working in my case (I lost ssh session during `do-release-upgrade` 14.04 -> 16.04). What I do instead as last step to finish the release upgrade is `sudo apt autoremove` and then `sudo shutdown -r now`. – Ruslan Stelmachenko May 22 '17 at 03:02
  • Found a more complete answer here which I followed upgrade automatically continued where it left off. https://askubuntu.com/questions/219545/dpkg-error-dpkg-status-database-is-locked-by-another-process#291584 – lacostenycoder Sep 23 '17 at 10:53
  • Bacon royally saved – Jeremy Cook Apr 15 '21 at 17:01
4

cryopid (found via this question) might help unless the current "one process, not a tree of processes" is a problem in this instance.

The files may be locked because the process was unceremoniously killed and didn't get chance to clean up after itself, so confirm that aptitude is actually still running. Use lsof /var/lib/dpkg/lock as suggested in Teddy's answer to check - this will tell you the pid to try cryopid on too.

In future I recommend to try running through screen where-ever possible. I have made a habit of screen (or byobu, which is a wrapper around screen that defines some useful behaviours) being the first thing I run when SSHing to anywhere then I can reconnect if there are issues. You can set it up to start or reattach automatically, though I've never got around to doing that anywhere - there are a number of examples online (this one for instance) if you want to try that.

Community
  • 1
David Spillett
  • 22,534
  • 42
  • 66
  • 1
    Incidentally, I preempted this and did a do-release-upgrade over ssh by using byobu, but when byobu was upgraded it killed my session! I wonder if using screen directly would have prevented this. But the other answer to this question answered my situation, seems like the installer is smart and runs its own screen session anyway :D – Ibrahim Jan 13 '13 at 09:24