华为云海外企业账号 弹性云服务器定时重启脚本
服务器为啥要定时重启？别让“永动机”变成“永动机故障”
想象一下，你的服务器就像一部连续开100小时的手机，再强的处理器也得累。内存泄漏、缓存堆积、临时文件爆炸……这些问题看似轻微，但时间一长，服务器就会像醉汉一样摇摇晃晃。定时重启就是给服务器“强制关机+重启”，相当于让手机休息一晚，第二天满血复活。不过，重启这事儿也得讲究，太频繁了伤身，不重启又容易瘫痪，怎么把握？别急，接下来手把手教你。
手把手教你写重启脚本（附完整代码）
别看“重启”两个字简单，真要写脚本，第一步得确认路径。有些系统用reboot，有些用shutdown -r now。先试试哪个好用，比如在终端输入sudo reboot，如果正常重启，那没问题。然后写个脚本：
#!/bin/bash
# 定时重启脚本，记录日志
LOG_FILE="/var/log/reboot.log"
echo "【重启日志】$(date)：开始重启" >> $LOG_FILE
# 使用shutdown -r now，比reboot更可靠
shutdown -r now
保存为reboot.sh，用chmod +x reboot.sh赋予执行权限。
测试脚本，别等定时任务出问题再慌
测试脚本时，千万别在生产环境直接执行。先找个测试机试试，或者用“延迟重启”模式。比如把shutdown -r now改成shutdown -r +1，这样1分钟后才重启，万一出问题还能及时cancel（shutdown -c）。如果测试时发现脚本没反应，先检查权限：ls -l reboot.sh，确保有x权限。如果还是不行，试试用绝对路径，比如/bin/shutdown -r now，因为crontab的环境变量可能不包含/bin路径。
设置定时任务：crontab的正确打开方式
用crontab -e编辑定时任务。想每天凌晨3点重启，就写：
0 3 * * * /root/reboot.sh
注意，这里的路径必须是绝对路径，因为crontab运行时的环境变量和你登录时不同。比如，如果你把脚本放在/home/user/，那就写/home/user/reboot.sh。
crontab的写法像密码，一不小心就出错。比如* * * * * 这五个星号分别代表分钟、小时、日、月、周几。想每天3点重启，就是0 3 * * *。记住，别把3写成15，不然半夜三点重启就变成下午三点，客户可能正在高峰期骂娘。
华为云海外企业账号 如果想每30分钟重启一次（不建议），可以写*/30 * * * *，但这样服务可能频繁中断，建议只在测试环境用。
不同云平台的注意事项
比如阿里云ECS实例，重启前请确认实例是否允许重启操作。有些云服务商可能有特殊限制，比如只允许通过API重启，但一般Linux系统里reboot命令还是能用的。不过，建议先查看云平台文档，避免误操作导致实例无法启动。腾讯云、华为云等也类似，但大多数情况下直接运行reboot命令没问题。当然，如果你用的是容器化环境，比如Docker，那重启宿主机和重启容器是两回事，别搞混了。
常见问题排查指南
脚本不执行？可能是这些原因
权限问题：crontab运行的用户是否有权限执行脚本？如果脚本需要sudo，需要在sudoers里配置NOPASSWD。比如：
echo "username ALL=(ALL) NOPASSWD: /sbin/shutdown" | sudo tee -a /etc/sudoers然后脚本里用sudo shutdown -r now。
环境变量：crontab默认环境变量有限，最好用绝对路径。比如用/bin/shutdown而不是shutdown。
日志检查：在脚本中添加日志记录，查看是否执行。比如在脚本开头写echo "run at $(date)" >> /tmp/cron.log，然后用tail -f /tmp/cron.log观察。
crontab是否生效：用crontab -l确认是否写入成功，或者检查系统cron日志，比如/var/log/cron。
重启后服务起不来怎么办？
重启后服务没启动，可能是服务没设置开机自启。比如nginx，用systemctl enable nginx。或者服务启动脚本有问题，检查日志：journalctl -u nginx.service。
或者可能系统启动时某些依赖没加载，比如网络服务。这时候需要检查系统启动顺序，或者添加wait-for-it脚本等待网络就绪。
高级玩法：智能重启，还是老老实实按计划来？
有人想让服务器自己“聪明”重启，比如监控内存使用率，超过90%就重启。写个脚本：
#!/bin/bash
USAGE=$(free | awk '/Mem/{printf("%.2f", $3/$2*100)}')
if (( $(echo "$USAGE > 90" | bc -l) )); then
echo "内存使用率$USAGE%，触发重启" >> /var/log/reboot.log
shutdown -r now
fi
但这种智能重启其实风险很大。比如内存高可能是因为有大量用户请求，重启会中断服务，反而更糟。或者某个进程占用了大量内存，但重启后可能恢复正常，但可能有更优的解决方案，比如优化代码、增加内存。所以建议不要轻易用自动重启，优先考虑人工干预或者更精准的监控告警。
结语：重启虽好，但别贪杯
定时重启脚本确实能解决很多问题，但记住：它不是万能药。关键是要结合实际业务场景。比如对外提供Web服务的服务器，可以在凌晨低峰期重启；而核心数据库，可能需要更谨慎。重启前务必备份数据、通知用户、确认服务状态。毕竟，服务器的稳定比什么都重要。下次重启时，别忘了给自己泡杯茶，看着服务器安静地重启，心里默念：“这次重启，一定能行！”——如果不行，那就再写个脚本，或者找专业的运维大佬帮忙。毕竟，运维这行，重启只是开始，解决问题才是王道。
