一、基本问题
Vm 中装的 Ubuntu16.0,由于未管理内存,现在已经满了,一共 20G 全用光了,且开机进不去系统;需要扩展内存,重新调整
二、解决思路
经过半天的奋战,遇到各种坑,总结后,保险的思路如下:
备份当前虚拟机 -> 给虚拟机扩展内存 20G -> 开机进入 recovery 模式的root用户 -> 删除系统 /var/log 下的日志文件(大概7个G) -> 开机进入系统安装gparted 重新调整分区 -> 文章末尾有彩蛋
三、开干(注:【】部分为我的具体情况)
A、备份当前虚拟机--防止后面操作失误,系统凉凉
步骤如下:先选中你要备份的系统【Ubunt-64】,点击【虚拟机】-> 【管理】-> 【克隆】,然后【下一步】->【下一步】->【创建完整克隆】->【下一步】-> 填写克隆位置和虚拟机名字【Ubunt16】 -> 【完成】等待完成即可;
B、在VM中给虚拟机增加内存20G
步骤如下:点击克隆好的虚拟机【Ubunt16】,可以看到内存只有20G,下面扩展,点击【编辑虚拟机设置】-> 【硬盘】-> 【扩展】(此处如果扩展不可点,需要删除所有快照)-> 弹出页面填写【40G】->【扩展】,等待完成即可;
C、开机进入recover模式,删除日志文件,先腾点空间,为了可以开机,安装gparted
详细步骤:
1、点击【开启虚拟机】时,鼠标定位到虚拟机,按住【 shift 键】,用方向键选择【Ubuntu 高级选项】-> 【回车】进入 -> 选择【recover mode】-> 【回车】进入 -> 选择【root】-> 【回车】进入;
2、输入如下命令查看,结果见下图:
df -h # 查看磁盘使用情况,可看到 sda1 使用率为 100%
cd /var/log/cups # 进入 文件夹
ls -lhS # 将文件以 从大到小顺序 展现,可以看到前两个日志文件有 7个G
rm -rf error_log error_log.1 # 删除这两个 贼大的日志文件
ls -lhS # 再次查看
df -h # 再次查看 使用率 为 63%
reboot # 重启 进入系统
重启后等待进入系统,熟悉的界面,开心 -_-
D、安装 gparted,重新分配 内存
步骤如下
1、安装gparted,报了一个 版本不兼容的错,解决方案是使用aptitude安装,通过降级依赖的软件解决依赖关系。过程记录如下
sudo apt-get update # 更新一哈
sudo apt-get install gparted # 安装 gparted ,居然报错了,还好这个错我见过,是版本的问题
# 使用aptitude安装,通过降级依赖的软件解决依赖关系
sudo apt-get install aptitude # 安装aptitude -- 使用aptitude软件包管理器
sudo aptitude install gparted n y y
# 第一个 n , 是不接受当前解决方案
# 第一个 y , 是接受 降级依赖软件 安装
# 第二个 y , 是允许安装
sudo gparted # 打开 gparted ,重新分配内存
2、重新调整分区,由于在 sda1 和 新加的20G 之间有 个 extend,所以不能直接 将这20G 扩展到 sda1,需要先删除 extend,配置好分区后,再重新添加 extend。
步骤如下:先在 【linux-swap】上右击,选择【禁用交换空间】;然后在右键删除【linux-swap】,右键删除【extend】;
下面就可以给 sda1 扩展了,在 sda1 那行右键,选择【更改大小】,弹出的窗口中,【滑块】滑到最右边,【之后的空余空间】填写2048(用于新建extend),点击【调整大小】;
然后在第二行右键,添加【扩展分区】,在第三行右键,添加【linux-swap】,最后点击提交【绿色对勾】,【确认】,结果如下。
E、大功告成!彩蛋在即!!!
总结一下,此次内存爆满的原因是 /var/log/cups/ 下 error_log 和 error_log.1 文件内容不断激增导致的,而且发现每次开机重启就会生成那个error_log文件,这个部分的问题,网上大概有两种解决方案:
1、是因为 /usr 权限过大导致的,需要改回原有权限(我的权限正常)
2、写个命令,定时删除 error_log 日志文件(没有找到根源,到底是谁向这个文件写入的内容)
sudo crontab -e
# 在打开的文件中加入如下内容,保存退出
*/2 * * * * echo "" > /var/log/cups/error_log
运行了下,确实增一会就会减少,说明这个删除有效,但是好傻啊
3、大彩蛋
经过谷歌查找,终于搞清楚了原理,还是得用google啊,终于找到的解决办法,哈哈哈哈!
先使用 tail 命令查看 error_log 文件打印的啥东西,原来是 那个路径的权限有问题,看准那个路径,不要写错
接着输入如下命令修改权限,重启服务,再次查看 error_log 文件内容,空空如也,爽哉!!
sudo chmod 755 /usr/lib/cups/notifier/dbus # 修改 这个路径的权限
sudo chown root.root /usr/lib/cups/notifier/dbus # 修改 归属用户
sudo rm /var/log/cups/error* # 删除 error 文件
sudo /etc/init.d/cups restart # 重启服务
tail error_log # 查看 error 文件,如果返回空,说明成功了
F、参考文献:
https://blog.csdn.net/weixin_44623010/article/details/97847484