How to safely abort apt-get install? 安全终止apt-get！

最新推荐文章于 2022-04-14 10:13:15 发布

转载最新推荐文章于 2022-04-14 10:13:15 发布 · 761 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://my.oschina.net/uniquejava/blog/225838

文章标签：

#数据库 #python #java

本文提供了两种有效的方法来解决Ubuntu系统中出现的apt-get故障问题。第一种方法包括终止apt-get进程、重新配置软件包以及更新并升级软件包。第二种方法则是通过移除引起故障的具体软件包来解决问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

2019独角兽企业重金招聘Python工程师标准>>>

方案一：

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

Kill the process named apt-get:
```
killall -9 apt-get
```
Reconfigure dpkg:
```
dpkg --configure -a
```
Update apt-get:
```
apt-get update
```
Update packages, including those improperly installed:
```
apt-get upgrade
```

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

方案二：

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

最终通过方案２搞定！

最佳答案（没什么作用）：

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 pressingCtrl+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 anapt-getoperation, 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 not catched 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.

转载于:https://my.oschina.net/uniquejava/blog/225838