发布网友 发布时间:2022-04-28 11:40
共1个回答
热心网友 时间:2023-10-06 13:53
以前启动实例都正常,今天发现error,然后查看nova manage service list,发现
nova-compute compute nova enabled ×× 2015-03-25 03:12:55
启动失败
遇到了两种情况,首先说一种遇到的情况
情况1:nova-compute异常
直接到计算节点启动服务:
service nova-compute start
start: Job is already running: nova-compute
已经启动,但在控制节点却不显示:于是先stop然后启动
root@compute:~# service nova-compute stop
nova-compute stop/waiting
root@compute:~# service nova-compute stop
stop: Unknown instance:
root@compute:~# service nova-compute start
nova-compute start/running, process 33532
最后启动成功
情况2:配置错误
提前透露原因:这位同事在/etc/nova/nova.conf配置文件中verbose = True 写成了 verbose =Ture,我也是检查了半天(两眼对了3遍)没看出来,有点汗!
根据我以前掌握的经验,OpenStack的部署过程遇到的问题可归纳总结为配置文件问题、配置步骤缺失等,因为通常计算机不会犯错,犯错的只有人类……
故障通常有以下几种情况:
时间同步问题,两(多)个节点间时间不同步
数据库问题,权限问题,数据库缺失,表结构不存在(数据库建立表结构时出错),用户名密码错误等
软件包没有正确安装,例如国外的源网络存在波动或网站存在故障或网站临时修改了源的路径等都会导致软件包安装出现重大错误,而安装的人却没有发现
配置文件中配置出错,这种错误最为常见,往往一个不易引人注意的错误就会出现问题,就如本文刚开始的第二段所说的一样,诸如此类还有把0写成o,把1写成l,service写成server等
网络接口地址用错,例如这次的排错步骤中还发现控制节点上的endpoint-list发现public url用的是错误地址,如本地环回地址而不是管理接口地址
服务用户缺失,一般由软件bug或软件安装不正确导致,如以前有rabbitmq需要的rabbitmq不存在,导致rabbitmq的guest密码不可修改等问题。
文件权限问题,如配置文件在更换后没有配置文件权限,例如本来是root:nova的文件所有者,被换成了root:root,一定会出现服务无法正常运行的问题。
通常排错方法总结如下:
检查软件日志和系统日志,这是第一步就要做的,如果没有生成软件日志就考虑查看系统日志,可以将/var/log/messages文件清空再执行一下相关的命令,查看此文件中的日志,可以在执行命令后没有生成日志的情况下使用此方法解决这一问题(在今天的故障排除中具有关键作用)。
删除软件包时要用rpm e packages而不要用yum erase packages,以免删除还需要用的依赖包
保留(备份)配置文件,重新安装软件包,yum reinstall packages
执行完不确定执行结果的命令后,用echo
$?检查执行结果,0为没有错,1以上为有严重错误,如执行su -s /bin/sh -c "nova-manage db sync"
nova时,如果遇到前面所说的数据库问题中的权限问题等就会出错,但此命令结束后并不报错。
认真比对配置文件,把注释行和空白行全部清除再做对比,grep v # /filepath/filename | grep v ^$可以实现删除注释行和空白行
坚定信念,计算机不会犯错,别人能成功,那一定是自己的错!
此次故障是如何排除的:
首先发现在控制节点上运行nova service-list发现只有4行,没有nova-compute service,可以联想到计算节点上的计算服务没有运行
经过执行systemctl
status openstack-nova-compute.service
-l查看详细结果,发现服务没有运行,而且显示openstack-nova-compute.service start request
repeated too quickly, refusing to start. Unit systemd-journald.socket
entered failed state.
此时查看nova-compute的日志文件/var/log/nova/nova-compute.log时发现文件不存在
因此,应该立刻联想到,配置文件(/etc/nova/nova.conf)一定有问题,但因为对比了2-3次后依然没有确定问题
此后我又检查了系统时间、数据库、文件权限、备份配置文件后重新安装软件包等是否存在问题,结果都全部正常,最后想到第7个步骤
可以通过系统日志查看服务启动失败的原因,先将/var/log/messages文件清空(true >/var/log/messages),再重启openstack-nova-compute.service
再观察/var/log/messages文件的内容,发现提示nova配置文件中非法的布尔型值ture,
因此在配置文件(/etc/nova/nova.conf)中找到ture的位置,将此单词改为正确的true,重新启动
在控制节点上执行校验命令nova service-list,确定无其他问题,successfully!
热心网友 时间:2023-10-06 13:53
以前启动实例都正常,今天发现error,然后查看nova manage service list,发现
nova-compute compute nova enabled ×× 2015-03-25 03:12:55
启动失败
遇到了两种情况,首先说一种遇到的情况
情况1:nova-compute异常
直接到计算节点启动服务:
service nova-compute start
start: Job is already running: nova-compute
已经启动,但在控制节点却不显示:于是先stop然后启动
root@compute:~# service nova-compute stop
nova-compute stop/waiting
root@compute:~# service nova-compute stop
stop: Unknown instance:
root@compute:~# service nova-compute start
nova-compute start/running, process 33532
最后启动成功
情况2:配置错误
提前透露原因:这位同事在/etc/nova/nova.conf配置文件中verbose = True 写成了 verbose =Ture,我也是检查了半天(两眼对了3遍)没看出来,有点汗!
根据我以前掌握的经验,OpenStack的部署过程遇到的问题可归纳总结为配置文件问题、配置步骤缺失等,因为通常计算机不会犯错,犯错的只有人类……
故障通常有以下几种情况:
时间同步问题,两(多)个节点间时间不同步
数据库问题,权限问题,数据库缺失,表结构不存在(数据库建立表结构时出错),用户名密码错误等
软件包没有正确安装,例如国外的源网络存在波动或网站存在故障或网站临时修改了源的路径等都会导致软件包安装出现重大错误,而安装的人却没有发现
配置文件中配置出错,这种错误最为常见,往往一个不易引人注意的错误就会出现问题,就如本文刚开始的第二段所说的一样,诸如此类还有把0写成o,把1写成l,service写成server等
网络接口地址用错,例如这次的排错步骤中还发现控制节点上的endpoint-list发现public url用的是错误地址,如本地环回地址而不是管理接口地址
服务用户缺失,一般由软件bug或软件安装不正确导致,如以前有rabbitmq需要的rabbitmq不存在,导致rabbitmq的guest密码不可修改等问题。
文件权限问题,如配置文件在更换后没有配置文件权限,例如本来是root:nova的文件所有者,被换成了root:root,一定会出现服务无法正常运行的问题。
通常排错方法总结如下:
检查软件日志和系统日志,这是第一步就要做的,如果没有生成软件日志就考虑查看系统日志,可以将/var/log/messages文件清空再执行一下相关的命令,查看此文件中的日志,可以在执行命令后没有生成日志的情况下使用此方法解决这一问题(在今天的故障排除中具有关键作用)。
删除软件包时要用rpm e packages而不要用yum erase packages,以免删除还需要用的依赖包
保留(备份)配置文件,重新安装软件包,yum reinstall packages
执行完不确定执行结果的命令后,用echo
$?检查执行结果,0为没有错,1以上为有严重错误,如执行su -s /bin/sh -c "nova-manage db sync"
nova时,如果遇到前面所说的数据库问题中的权限问题等就会出错,但此命令结束后并不报错。
认真比对配置文件,把注释行和空白行全部清除再做对比,grep v # /filepath/filename | grep v ^$可以实现删除注释行和空白行
坚定信念,计算机不会犯错,别人能成功,那一定是自己的错!
此次故障是如何排除的:
首先发现在控制节点上运行nova service-list发现只有4行,没有nova-compute service,可以联想到计算节点上的计算服务没有运行
经过执行systemctl
status openstack-nova-compute.service
-l查看详细结果,发现服务没有运行,而且显示openstack-nova-compute.service start request
repeated too quickly, refusing to start. Unit systemd-journald.socket
entered failed state.
此时查看nova-compute的日志文件/var/log/nova/nova-compute.log时发现文件不存在
因此,应该立刻联想到,配置文件(/etc/nova/nova.conf)一定有问题,但因为对比了2-3次后依然没有确定问题
此后我又检查了系统时间、数据库、文件权限、备份配置文件后重新安装软件包等是否存在问题,结果都全部正常,最后想到第7个步骤
可以通过系统日志查看服务启动失败的原因,先将/var/log/messages文件清空(true >/var/log/messages),再重启openstack-nova-compute.service
再观察/var/log/messages文件的内容,发现提示nova配置文件中非法的布尔型值ture,
因此在配置文件(/etc/nova/nova.conf)中找到ture的位置,将此单词改为正确的true,重新启动
在控制节点上执行校验命令nova service-list,确定无其他问题,successfully!