動作環境
Xeon E5-2620 v4 (8コア) x 2
32GB RAM
CentOS 6.8 (64bit)
NCAR Command Language Version 6.3.0
for WRF3.7.1, WPS3.7.1
openmpi-1.8.x86_64 とその-devel
mpich.x86_64 3.1-5.el6とその-devel
gcc version 4.4.7 (とgfortran)
for WRF3.9, WPS3.9
Open MPI v2.1.1
gcc version 4.9.2 (とgfortran; devtoolset-3使用)
NetCDF v4.4.1.1, NetCDF (Fortran API) v4.4.4
Python 2.6.6 (r266:84292, Aug 18 2016, 15:13:37)
Python 3.6.0 on virtualenv
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
date (GNU coreutils) 8.4
tmux 1.6-3.el6
cronの設定では20:30にバックアップツールを動かしているだけ。
$ last | grep reboot
reboot system boot 2.6.32-642.el6.x Tue Mar 6 14:05 - 09:02 (18:57)
reboot system boot 2.6.32-642.el6.x Mon Feb 26 09:53 - 09:02 (8+23:09)
reboot system boot 2.6.32-642.el6.x Mon Jan 29 18:42 - 09:02 (36+14:20)
reboot system boot 2.6.32-642.el6.x Wed Jan 17 09:41 - 09:02 (48+23:20)
reboot system boot 2.6.32-642.el6.x Mon Dec 11 13:47 - 10:43 (17+20:55)
reboot system boot 2.6.32-642.el6.x Fri Sep 8 18:59 - 10:43 (111+15:43)
reboot system boot 2.6.32-642.el6.x Mon Mar 27 09:32 - 11:50 (165+02:17)
reboot system boot 2.6.32-642.el6.x Mon Jan 16 18:48 - 19:10 (67+00:21)
...
lastコマンドを再実行すると、08:49が09:00になった。
現在時刻の7分前(6分前?)の日時になっているようだ。
再起動してみた。
$ last | grep reboot
reboot system boot 2.6.32-642.el6.x Wed Mar 7 09:07 - 09:11 (00:04)
reboot system boot 2.6.32-642.el6.x Tue Mar 6 14:05 - 09:05 (19:00)
reboot system boot 2.6.32-642.el6.x Mon Feb 26 09:53 - 09:05 (8+23:12)
reboot system boot 2.6.32-642.el6.x Mon Jan 29 18:42 - 09:05 (36+14:23)
reboot system boot 2.6.32-642.el6.x Wed Jan 17 09:41 - 09:05 (48+23:23)
reboot system boot 2.6.32-642.el6.x Mon Dec 11 13:47 - 10:43 (17+20:55)
reboot system boot 2.6.32-642.el6.x Fri Sep 8 18:59 - 10:43 (111+15:43)
右側の日時が同じになる症状は解消された。
使用履歴
- sshで接続
- tmuxを使用
- tmuxを使用の状態でターミナルをクローズ
- sshで接続
- tmux attach -dでtmuxを再開
- 手順4から繰返す
tmuxが残っているかと思いps auxなどで確認したが、複数の起動は見つからなかった。
link
-
Meanings of the columns in “last” command
- > For me, the most recent reboot entry shows the current time as the "logged off" time, and the session duration data for that entry matches the current uptime output.
- by shavais
/var/log/messages
(追記 2018/03/07)
@tukiyo3 さんのアドバイスに基づき、/var/log/messagesを確認してみました。
2018/03/04 08:37:02以降のログが残っており、再起動日時で関連しそうなログは下記でした。
/var/log/messages
Mar 6 14:05:31 localhost NetworkManager[5021]: <info> Activation (eth0) successful, device activated.
Mar 6 14:05:31 localhost NetworkManager[5021]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete.
Mar 6 14:05:31 localhost abrtd: Init complete, entering main loop
Mar 6 14:05:36 localhost polkitd[5660]: started daemon version 0.96 using authority implementation `local' version `0.96'
Mar 7 09:05:52 localhost init: tty (/dev/tty2) main process (5452) killed by TERM signal
Mar 7 09:05:52 localhost init: tty (/dev/tty3) main process (5454) killed by TERM signal
Mar 7 09:05:52 localhost init: tty (/dev/tty4) main process (5456) killed by TERM signal
Mar 7 09:05:52 localhost init: tty (/dev/tty5) main process (5458) killed by TERM signal
Mar 7 09:05:52 localhost init: tty (/dev/tty6) main process (5460) killed by TERM signal
Mar 7 09:05:55 localhost abrtd: Got signal 15, exiting
Mar 7 09:05:59 localhost acpid: exiting
Mar 7 09:06:01 localhost NetworkManager[5021]: <info> caught signal 15, shutting down normally.
Mar 7 09:06:01 localhost NetworkManager[5021]: <info> (eth1): cleaning up...
2018/03/07 09:05:52は該当サーバーの近傍で作業しており、該当サーバーの電源関連は触っていませんでした。
別途、気になっていたのは、2018/03/06 10:40頃からWRFという数値計算ソフトを走らせており、20:00頃までに終了通知メールが届く予定でした。メールはその日時までに届いていませんでした。
再度、同じWRFの計算を走らせたところ、メール送信処理まで完了しました。