8

I was connected to my aws debian wheezy server and while running apt-get upgrade the ssh pipe broke. I didn't use screen or anything, so I don't think there's a way to recover that session.

If I reconnect with a new ssh session and run ps aux | grep apt, I can see that apt and dpkg are still running

They've been running for hours actually. I can't imagine that it would be safe to kill those processes as they might be modifying system libs/binaries, but what can I do? What if they are waiting for keyboard input or the like? I had said y when apt originally asked me to install the updates, but I don't know if it needed further user input. I plan on waiting a few more hours for dpkg and apt to hopefully complete what they're doing.. but if nothing happens, what are my options?

Improve this question
4
  • 1
    I personally always use tmux over SSH, so I could never encounter such a problem. GNU screen or dtach should both be good alternatives.
    – sshilovsky
    Sep 20, 2014 at 7:54
  • I'm not sure this will work, but you might be able to bring the processes back to the foreground with fg.
    – HalosGhost
    Sep 20, 2014 at 8:05
  • I think fg and bg only work for attached processes started in the current tty session ("jobs")
    – Felix Mc
    Sep 20, 2014 at 18:07
  • Can't you reattach to the process using gdb?
    – Faheem Mitha
    Sep 21, 2014 at 21:14

4 Answers 4

Reset to default
2

I think it is ok to send them a SIGINT (keyboard interruption, i.e. Ctrl+C) signal:

killall -SIGINT apt-get

or

killall -2 apt-get

You may also try to do it twice or more

Improve this answer
2
  • did that a few times but with no effect :(
    – Felix Mc
    Sep 20, 2014 at 18:00
  • Killing it with -SIGTERM worked for me, thank you
    – Andrei
    Mar 19, 2016 at 20:01
2

You can't regain the session. And so you cannot do anything to interact with that process.

I don't think the process is running. I guess the apt-get might have become a zombie by now. Anyway you can check the process using ps or top. If it's running, then let go and monitor it to finish. If it stays idle just kill it.

And then you can simply run apt-get upgrade once again after killing the process, to finish or repair any package being upgraded while the session crashed.

Improve this answer
2

You can try to reattach the session with a tool like reptyr, but that doesn't always work.

You can kill apt, dpkg and their subprocesses at any time. All package maintenance tasks are supposed to resist a sudden power failure. Run the command again to complete it.

Make sure to send a SIGINT or SIGTERM signal to APT and dpkg, not a SIGKILL. A SIGKILL would leave lock files in place. This is a general principle: don't use SIGKILL when SIGINT would do.

Improve this answer
1
  • > All package maintenance tasks are supposed to resist a sudden power failure I don't know about latest debian versions, but with debian 4-5 I had got into a trouble supposing this
    – sshilovsky
    Sep 22, 2014 at 8:32
0

This helped me to do better in the future: use 'screens'

This Debian post helped me to fix my acute problem:

https://wiki.debian.org/Teams/Dpkg/FAQ

sudo fuser -vki -TERM /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend

sudo dpkg --configure --pending
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .