6

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?

  • 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 '14 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 '14 at 8:05
  • I think fg and bg only work for attached processes started in the current tty session ("jobs") – Felix Mc Sep 20 '14 at 18:07
  • Can't you reattach to the process using gdb? – Faheem Mitha Sep 21 '14 at 21:14
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

  • did that a few times but with no effect :( – Felix Mc Sep 20 '14 at 18:00
  • Killing it with -SIGTERM worked for me, thank you – Andrei Mar 19 '16 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.

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.

  • > 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 '14 at 8:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.