环境背景
系统环境
本地 Ubuntu 16.04 的虚拟机
需求
在项目开发中,功能开发完成后需要修改项目内时间来完成自测,而项目内的时间通常是通过读取系统时间获得
实操过程
第一次尝试
Linux 环境下修改系统时间,第一时间想到的就是 date 命令,在以前的项目开发中也经常用(但是原来的项目 Linux 环境并不需要起本地虚拟机),然后我就通过 sudo date -s '2019-11-1 11:21:45'
尝试修改时间,但是之后再调用 sudo date
命令,发现修改并没有生效(重复 N 次)
第二次尝试
发现 date 不能用了,首先是咨询了一下测试人员(毕竟测试相对开发调时间的次数更多些),然后测试人员告诉我,他的也不生效,每次修改都是在图形界面下完成的。。。但这种方式对于我来说没有办法忍受,一是图形化界面更加吃内存资源(除了起虚拟机,还要用 IDE 的,能省则省),二是图形界面操作不舒服(比不上常用的 XShell)。
于是开始上网搜索解决方案,发现多是先 sudo date -s '2018-11-11 11:11:11'
,然后sudo hwclock --systohc
,中间可能穿插着sudo cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
修改时区的操作,我将信将疑地试了几次,也修改过自己物理机的本地时间,发现并没有啥用,唯一的效果可能就是增加了我对这几个命令的熟悉程度。
第三次尝试(最后一次)
多次设置都失败,开始考虑是否是系统中的哪些东西禁止了我的修改时间操作,或者暗中修改了我的时间。通过这个思路查询资料,最终找到了问题的根源:我并不是没有修改成功,而是系统的 NTP 服务在我修改成功后又将时间同步回去了,而我需要做的,其实是先关闭 NTP 的同步机制,然后再进行时间修改就能成功。
解决方案
timedatectl set-ntp false
sudo date -s '2019-11-1 11:21:45'
此时通过命令查看时间的话,就可以发现日期修改成功了,而如果需要将时间同步回去,直接执行 timedatectl set-ntp true
即可
总结思考
这次解决问题在没有正确的思路前花了很多的时间,这是由于一些知识盲区导致的(并不知道有 timedatectl 命令的存在,除了 date 命令,对于其他的也知之甚少,所以绕了很多弯路)。知识盲区是难以避免的,只能做到努力去学习、积累;但是并不代表没有办法更快地解决问题,下次再出了类似的问题,如果先凭借自己的积累和经验去触类旁通的定位可疑点,然后再查阅相关资料,相信无论是对于解决问题速度还是解决问题能力的提升都是有帮助的。