64

I have an apt-get install process that seems to be hopelessly wedged at the processing triggers for python-support step.

My inclination is to kill it, but in the past, simply kill-ing an apt-get install process has caused me much grief. (IIRC assorted lock files are left behind, etc.)

Is there a safer way to stop this process?

Improve this question

6 Answers 6

Reset to default
63

Killing processes

Generally speaking for killing a process, there's no safer way to kill a process than with a regular kill (SIGTERM). In case it's an interactive process it usually allows you to stop it even safer by sending a SIGINT signal, usually sent by pressing Ctrl + C. This signal is being trapped by the process itself can listen to it - and usually stop gracefully. (thanks Eliah)

DPKG database

Regarding the package management is a sort of special case. The DPKG database that the APT commands use under water can always detect whether an operation hasn't finished. Every package has an actual state which is marked in as well as a current state, e.g. unpacked, configured, etc. By killing the APT frontend, the database will be in a broken, but in known state. The lock files will only be released once it's all back in a clean state - you should get this fixed until it allows new operations.

The way to fix is just firing a process to get all packages in the configured state. Practically speaking, if you've interrupted an apt-get operation, you can just finish it later using

sudo dpkg --configure -a

It knows how to recover from the broken state to an all-configured state and in that sense just continue from where it was interrupted. The lock files are left there until you finished that, and that's for a reason - to prevent new operations with the DPKG database in an unclean state.

About SIGKILL (9)

Sending a SIGKILL (decimal representation 9) is very unsafe. This signal is cannot be caught by the process, but the whole process will be cleaned up by the operating system (kernel) whether the process likes it or not. The state of the files on the file system can be left in a corrupt state. Never send these signals unless it's not listening to other more graceful signals anymore.

Improve this answer
1
  • 4
    When an application offers a way to terminate it, that's usually even safer than SIGTERM. For example, most (if not all) text editors, word processors, graphics programs, web browsers, and other text-based or graphical apps where a user is likely to create content that shouldn't be lost, do not auto-save it before quitting when they receive SIGTERM. Also, please note that SIGINT might sometimes be safer than SIGTERM (but should not generally be sent unless the same result as Ctrl+C is explicitly desired).
    – Eliah Kagan
    Feb 11, 2013 at 19:59
19

When I encounter a failure with apt-get, I do the following (as root, i.e. sudo before all commands):

  1. Kill the process named apt-get:

    killall -9 apt-get

  2. Reconfigure dpkg:

    dpkg --configure -a

  3. Update apt-get:

    apt-get update

  4. Update packages, including those improperly installed:

    apt-get upgrade

This I learned from somewhere, but unfortunately I cannot remember exactly where.

Improve this answer
2
  • 11
    Please never send a signal 9 (SIGKILL) unless you have a very good reason to do so. See my updated answer.
    – gertvdijk
    Feb 11, 2013 at 21:38
  • step 2 just does not work as the dpkg is locked. needed to run sudo rm /var/lib/dpkg/lock sudo rm /var/lib/dpkg/lock-frontend sudo rm /var/cache/apt/archives/lock First
    – Dave
    Jul 14, 2022 at 19:48
3 
sudo dpkg -r <package name>

In my case I had problems with Java 8 on Ubuntu 12.04, so...

sudo dpkg -r oracle-java8-installer
Improve this answer
1

Here is how I do it, Ctrl+C But mind you that it is safe as long as apt-get is in downloading phase or its updating the cache. Other than that I cannot think a way that is safer. Just let it finish and undo changes by uninstalling or downgrading somehow. The downloaded files can be cleaned with sudo apt-get autoclean

Improve this answer
1

If Advanced Package Tool (APT) is hung, then the /var/lib/dpkg/lock and /var/lib/dpkg/lock-frontend lock files are probably held. You can run the following procedure—described by the Debian Wiki in the Q: What can be done when the dpkg lock is held? section.

  1. Kill the process holding the lock files.

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

    The following options are passed to the fuser command—a command to identify processes using files or sockets:

    • -v, --verbose Enable verbose mode.
    • -k, --kill Kill processes accessing the file. Unless changed with -SIGNAL, SIGKILL is sent. In this case, the -TERM switch indicates a SIGTERM signal is sent.
    • -i, --interactive Ask the user for confirmation before killing a process.

    Note: If—despite your best efforts—the -TERM option doesn't work, then consider increasing the force of your fuser command and send a SIGKILL signal with the following command: sudo fuser -vki -KILL /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend

  2. Complete dpkg pending configuration steps.

    sudo dpkg --configure --pending
Improve this answer
0

Linux and other Unix type systems are very powerful from the command line but very unforgiving once a process has started. Sending a process the kill signal will certainly kill the process that is running but bear in mind that you are leaving a database in an unstable state. The last record may not be closed out correctly so you risk have to repair a database. Not just with apt but with any application.

Always try to end the application in a normal manner and only kill processes that are run away applications.

Improve this answer

You must log in to answer this question.

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