GVKun编程网logo

无法删除状态为 Dead 的容器（无法删除/var/lib/dpkg/lock）

8

本文将分享无法删除状态为Dead的容器的详细内容，并且还将对无法删除/var/lib/dpkg/lock进行详尽解释，此外，我们还将为大家带来关于(Oracle)：处于部分删除状态的列、CAD图层无法

本文将分享无法删除状态为 Dead 的容器的详细内容，并且还将对无法删除/var/lib/dpkg/lock进行详尽解释，此外，我们还将为大家带来关于(Oracle)：处于部分删除状态的列、CAD图层无法删除怎么办？CAD删除顽固图层方法、DataNode进程还在，但是50070Wed端显示DataNode状态为Dead、destroyPersistentStore 无法删除持久存储 - CoreData：错误：无法删除支持目录的存储的相关知识，希望对你有所帮助。

本文目录一览：

无法删除状态为 Dead 的容器（无法删除/var/lib/dpkg/lock）

无法删除状态为 Dead 的容器（无法删除/var/lib/dpkg/lock）

docker 中有两个 status 为 dead 的容器

[root@xinyan001 ~]# docker ps -a
CONTAINER ID        IMAGE                COMMAND             CREATED             STATUS                      PORTS               NAMES
13dd233a61c5        fedora-base:latest   "/bin/bash"         25 minutes ago      Dead                                                                 
9b8fcf405ffc        fedora-base:latest   "/bin/bash"         About an hour ago   Exited (0) 41 minutes ago                       gloomy_ardinghelli   
7f2ca6d2801d        fedora-base:latest   "/bin/bash"         About an hour ago   Dead                                      
删除时

[root@xinyan001 ~]# docker rm 13dd233a61c5 7f2ca6d2801d 
Error response from daemon: Cannot destroy container 13dd233a61c5: Driver devicemapper failed to remove root filesystem 13dd233a61c509e2e56bd970dc7cecc7b44892ed0dacce117c3624ceee9f92f5: Device is Busy
Error response from daemon: Cannot destroy container 7f2ca6d2801d: Driver devicemapper failed to remove root filesystem 7f2ca6d2801dcc3b2cebd0b6b246a91a1093a5ae427b5349631ffd61f0306424: Device is Busy
FATA[0024] Error: failed to remove one or more containers 

Device is Busy 这个一般的解决步骤：
1. 看容器进程是否已经杀掉。没有的话，可以手动杀死。

[root@xinyan001 ~]# ps -ef |grep docker
root      4363     1  0 2 月 08 ?       00:00:18 /usr/bin/docker -d --selinux-enabled
root      7785  7766  3 11:30 pts/0    00:00:55 docker -d
root      9013  5426  0 11:56 pts/1    00:00:00 grep --color=auto docker
2. mount -l 看是不是该容器的路径还在挂载状态。是的话，umount 掉。

[root@xinyan001 ~]# mount -l
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=16361216k,nr_inodes=1022576,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/sda2 on / type ext4 (rw,relatime,data=ordered)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=28,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
/dev/sda1 on /boot type ext3 (rw,relatime,data=ordered)
/dev/sda6 on /opt type ext4 (rw,relatime,data=ordered)
/dev/sda3 on /home type ext4 (rw,relatime,data=ordered)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/user/990 type tmpfs (rw,nosuid,nodev,relatime,size=3273920k,mode=700,uid=990,gid=984)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=3273920k,mode=700)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/sda2 on /var/lib/docker/devicemapper type ext4 (rw,relatime,data=ordered)
/dev/mapper/docker-8:2-22283855-7f2ca6d2801dcc3b2cebd0b6b246a91a1093a5ae427b5349631ffd61f0306424 on /var/lib/docker/devicemapper/mnt/7f2ca6d2801dcc3b2cebd0b6b246a91a1093a5ae427b5349631ffd61f0306424 type ext4 (rw,relatime,discard,stripe=16,data=ordered)
/dev/mapper/docker-8:2-22283855-13dd233a61c509e2e56bd970dc7cecc7b44892ed0dacce117c3624ceee9f92f5 on /var/lib/docker/devicemapper/mnt/13dd233a61c509e2e56bd970dc7cecc7b44892ed0dacce117c3624ceee9f92f5 type ext4 (rw,relatime,discard,stripe=16,data=ordered)
[root@xinyan001 ~]# umount /dev/mapper/docker-8:2-22283855-7f2ca6d2801dcc3b2cebd0b6b246a91a1093a5ae427b5349631ffd61f0306424 
[root@xinyan001 ~]# umount /dev/mapper/docker-8:2-22283855-13dd233a61c509e2e56bd970dc7cecc7b44892ed0dacce117c3624ceee9f92f5
3. 然后再次尝试 docker rm。

[root@xinyan001 ~]# docker rm 13dd233a61c5 7f2ca6d2801d 
13dd233a61c5
7f2ca6d2801d

(Oracle)：处于部分删除状态的列

(Oracle)：处于部分删除状态的列

我使用的是Oracle 10g.几个月以来我对表有以下错误： 

ORA-12986: columns in partially dropped state. Submit ALTER TABLE DROP COLUMNS CONTINUE

ALTER TABLE DROP COLUMNS CONTINUE语句因加班而失败.

我没有此数据库的DBA权限.

我能做什么？掉落&重新创建表？

这是一张拥有数百万条记录的大桌子.

我尝试了什么：

>曾几何时,我做了以下命令来设置一些列
处于未使用状态：

ALTER TABLE hr.admin_emp SET UNUSED (hiredate,mgr);

然后,我给出了以下命令：

ALTER TABLE hr.admin DROP UNUSED columns;

系统挂起,操作太长,故障.

现在表hr.admin有两列处于部分删除状态,
我既不能前进,也不能后退.

我不明白为什么会这样.
>我做了以下步骤,系统挂起了第二阶段：

第一阶段
 ============

sql> select * from user_unused_col_tabs;

TABLE_NAME  COUNT
----------- ----------
TEMP        1

第二阶段
 ============

sql> alter table temp drop unused columns;

Table altered.

第三阶段
 =============

sql> select * from user_unused_col_tabs;

no rows selected

> Checkpoint 500选项

我再次尝试以下声明：

ALTER TABLE MYUSER.MYTABLE DROP COLUMNS CONTINUE CHECKPOINT 500;

CHECKPOINT 500选项可以帮助我吗？

解决方法

我们连续给出了大约12次命令： 

ALTER TABLE MYUSER.MYTABLE DROP COLUMNS CONTINUE CHECKPOINT 250;

该声明每48小时自动杀死一次,这是因为我们不得不多次启动它.

大约500个小时的精心设计,以确保在部分掉落的状态下放下柱子…… !!

确认CHECKPOINT 250进行“提交”,因此在下次启动相同命令时,您将从停止点开始.

CAD图层无法删除怎么办？CAD删除顽固图层方法

CAD图层无法删除怎么办？CAD删除顽固图层方法

有很多朋友删除图层时会提示图层中有东西或图层被参照。然而好多办法都非常麻烦，我们不如换个思路，合并图层，把那些乱七八糟的图层都合并成一个图层。

1、删除图层不成功。

2、那我们就 合并图层。

3、把要 删除的图层合并到你要底层。

4、成功，该死的图层没有了。

注意事项： 前提要确定你要删的图层里面，没有可见的东西。

DataNode进程还在，但是50070Wed端显示DataNode状态为Dead

DataNode进程还在，但是50070Wed端显示DataNode状态为Dead

hadoop2.x中加yarn

一、关闭处于dead状态节点的datanode、nodemanager进程

hadoop-daemon.sh stop datanode

yarn-daemon.sh stop nodemanager

二、重启dead状态节点的datanode、nodemanager进程

hadoop-daemon.sh start datanode

yarn-daemon.sh start nodemanager

 

destroyPersistentStore 无法删除持久存储 - CoreData：错误：无法删除支持目录的存储

destroyPersistentStore 无法删除持久存储 - CoreData：错误：无法删除支持目录的存储

如何解决destroyPersistentStore 无法删除持久存储 - CoreData：错误：无法删除支持目录的存储？

我正在尝试从我的 Swift 代码中删除一个持久存储。每次尝试时，商店都不会被删除，并且我收到一个错误，该错误未在 catch 块中捕获，说明以下内容：

CoreData：错误：无法删除商店的支持目录：/var/mobile/Containers/Data/Application/8292CDAE-8AE4-4353-8F4C-0EB12CF119CC/Library/Application Support/Chapter.sqlite

当我检查时，所有文件都在那里，Chapter.sqlite、Chapter.sqlite-shm 和 Chapter.sqlite-wal。什么都没有删除。我想，根据其他一些帖子，商店里可能有一把锁。但是，即使我重新启动应用程序，我也遇到了这个问题，我尝试的第一件事是使用以下代码删除商店：

container = NSPersistentContainer( name: "Chapter" )
do {
            let url = getApplicationSupportDirectory().appendingPathComponent("Chapter.sqlite")
            
            try container.persistentStoreCoordinator.destroyPersistentStore(at: url,ofType: NSsqliteStoreType,options: nil)
        }
        catch {
            print( error )
        }

我也尝试先加载商店，使用以下方法从加载的商店中获取 url：

container.loadPersistentStores { description,error in
            caughtError = error as NSError?
        }

do {
            let store = container.persistentStoreCoordinator.persistentStores.last!
            
            //try container.persistentStoreCoordinator.remove(store)
        
            try container.persistentStoreCoordinator.destroyPersistentStore(at: store.url!,options: nil)
        }
        catch {
            print( error )
        }

我遇到了同样的错误，包括已注释和未注释行 container.persistentStoreCoordinator.remove(store)。

商店根本不会被删除。甚至不是 .sqlite 文件。有没有人遇到过这样的问题？你是怎么解决的？还有其他方法可以删除持久存储吗？我想我可以使用 FileManager“手动”删除文件，但我担心这可能会带来它自己的问题。提前致谢。

编辑：

这里是 getApplicationSupportDirectory 回复@TomHarrington：

func getApplicationSupportDirectory() -> URL {
    let paths = FileManager.default.urls(for: .applicationSupportDirectory,in: .userDomainMask)
    let documentsDirectory = paths[0]
    return documentsDirectory
}

致@ElTomato，不幸的是没有，Unable to destroy persistent store created with Core Data and SQLite 没有为我解决。我没有将扩展名为 .mmod 的文件传递给 destroyPeristentStore，而是传递 .sqlite 文件。此外，我在其中一次尝试中使用了直接从从 persistentStoreCoordinator.persistentStores 获得的存储对象中获取的 url

解决方法

暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！

如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。

小编邮箱:dio#foxmail.com (将#修改为@）

关于无法删除状态为 Dead 的容器和无法删除/var/lib/dpkg/lock的问题就给大家分享到这里，感谢你花时间阅读本站内容，更多关于(Oracle)：处于部分删除状态的列、CAD图层无法删除怎么办？CAD删除顽固图层方法、DataNode进程还在，但是50070Wed端显示DataNode状态为Dead、destroyPersistentStore 无法删除持久存储 - CoreData：错误：无法删除支持目录的存储等相关知识的信息别忘了在本站进行查找喔。

本文标签：

上一篇PHP的包括错误没有findind路径（php找不到指定模块）

下一篇docker 运行命令出现 "Failed to get D-Bus connection"（docker failed to start）

相关文章