“마지막”명령의 열 의미

정기적으로 재부팅하는 서버를 조사 할 때 "마지막"유틸리티를 살펴보기 시작했지만 문제는 열의 정확한 의미를 찾을 수 없다는 것입니다. 물론 남자를 살펴 보았지만이 정보는 포함되어 있지 않습니다.

root@webservice1:/etc# last reboot   
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 09:44 - 09:58  (00:13)    
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 09:34 - 09:43  (00:08)    
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 09:19 - 09:33  (00:13)    
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 08:51 - 09:17  (00:25)    
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 00:11 - 09:17  (09:05)    
reboot   system boot  3.2.13-grsec-xxx Wed Apr 11 19:40 - 09:17  (13:36)    
reboot   system boot  3.2.13-grsec-xxx Sun Apr  8 22:06 - 09:17 (3+11:10)   
reboot   system boot  3.2.13-grsec-xxx Sat Apr  7 14:31 - 09:17 (4+18:45)   
reboot   system boot  3.2.13-grsec-xxx Fri Apr  6 10:20 - 09:17 (5+22:56)   
reboot   system boot  3.2.13-grsec-xxx Thu Apr  5 00:16 - 09:17 (7+09:01)   
reboot   system boot  3.2.13-grsec-xxx Tue Apr  3 07:34 - 09:17 (9+01:42)   
reboot   system boot  3.2.13-grsec-xxx Tue Apr  3 02:31 - 09:17 (9+06:45)   
reboot   system boot  3.2.13-grsec-xxx Mon Apr  2 23:17 - 09:17 (9+09:59)   

첫 번째 열은 포함 된 커널 버전에 따라 다릅니다. 이 시대는 정확히 무엇을 나타 냅니까? 마지막은 가동 시간 인 것 같습니다.

둘째, 시간이 맞지 않는 것을 제외하고는 24/7에 서버로 작동해야합니다. 이는 다운 타임이나 이와 유사한 것을 경험할 수 있음을 의미합니다. 예를 들어, 마지막 두 줄을 보면 서버가 4 월 2 일 09:17에서 4 월 3 일 02:31까지 꺼져 있다는 의미입니까?

배경 정보는 데비안 스퀴즈 서버입니다.

편집하다

마지막 열이 시작 시간, 중지 시간 및 가동 시간 인 경우 다음 두 줄을 어떻게 해석 할 수 있습니까?

reboot   system boot  3.2.13-grsec-xxx Tue Apr  3 07:34 - 09:17 (9+01:42)   
reboot   system boot  3.2.13-grsec-xxx Tue Apr  3 02:31 - 09:17 (9+06:45)   

두 번째 세션은 첫 번째 세션이 시작된 후에 끝나는 것 같습니다.

나는 이것이 3 살짜리 게시물이라고 생각하지만, 내가 방금 최근에 한 것처럼 앞으로 그것을 통해 다른 사람들의 이익을 위해 어쨌든 응답 할 것입니다.

다른 게시물을 읽고 일정 시간 동안 출력을 직접 모니터링하면 각 줄에 세션의 시작 날짜와 시간, 세션의 종료 시간 (종료 날짜는 아님) 및 세션 기간이 나열되는 것처럼 보입니다. (로그인 한 시간)과 같은 형식으로

(일 + 시간 : 분)

재부트 사용자는 시스템을 시작할 때마다 로그인 한 것으로 표시되고 시스템을 재부트하거나 종료 할 때 로그 오프 된 것으로 표시되며, 이러한 회선에서 "세션 기간"정보는 시간 (일 + 시간 : 분)입니다. "세션"이 지속되었습니다. 즉, 시스템이 종료되기 전에 시스템이 가동 된 시간입니다.

나에게 가장 최근의 재부팅 항목은 현재 시간을 "로그 오프"시간으로 표시하고 해당 항목의 세션 시간 데이터는 현재 가동 시간 출력과 일치합니다.

따라서이 줄에 :

재부팅 시스템 부팅 3.2.13-grsec-xxx 화요일 4 월 3 일 07:34-09:17 (9 + 01 : 42)

이 시스템은 4 월 3 일 화요일 오전 7시 34 분에 시작되었으며 오전 9시 17 분에 9 일 1 시간 42 분 후에 (4 월 12 일) 종료되었습니다. 또는이 출력은 당시에 수집되었으며 가장 최근의 재부팅 항목이며 "reboot"는 실제로 "로그 오프"되지 않았습니다.이 경우 마지막 명령을 다시 실행하면 출력이 변경됩니다.

4 월 3 일에 9 일 동안 재부팅 한 사용자에 대해 2 개의 항목이있는 이유는 미스터리입니다. 내 시스템은 그렇게하지 않습니다.

요약

• 첫 번째 타임 스탬프는 재부팅하는 동안 시스템이 다운 된 시간 인 것으로 보입니다.
• 두 번째 타임 스탬프와 경과 시간은 그다지 유용하지 않습니다.
• -x옵션을 전달하면 라인에 last표시된 타임 스탬프에 영향을주는 종료 및 실행 레벨 변경과 관련된 다른 이벤트를 표시하는 데 유용 할 수 있습니다 reboot. tuptime다른 답변에서 언급 한 도구로이를 더 명확하게 만들 수는 있지만 보지 않았습니다.

세부

lastCentOS 6 및 7 의 매뉴얼 페이지는 다음과 같이 말합니다.

의사 사용자 재부팅은 시스템이 재부팅 될 때마다 로그인됩니다.

사용자가 로그 아웃하는 시점에 대해서는 아무 것도 말하지 않으며 아래 표시된 증거는 로그 아웃 시간이 명시 적으로 기록되지 않았 음을 암시하는 것으로 보입니다. reboot및 shutdown매뉴얼 페이지 사람이 관심을 경우 실행 레벨 변경 기록에 대한 자세한 내용을 가지고있다.

테스트 결과 로그인 시간이 늦게 종료 된 것으로 보입니다. reboot . 명령이 실행 된 .

따라서 로그 아웃 시간 (두 번째 타임 스탬프) 및 "재부팅"이 로그인 된 기간 (괄호 안에 표시)은 무시해야합니다.

-F옵션을에 전달 last하면 전체 타임 스탬프가 표시되므로 시스템이 동시에 우발적으로 재부팅되지 않는다는 것이 약간 더 명확 해집니다. 몇 번의 정확한 타임 스탬프 만 표시됩니다. 또한 -x플래그 를 전달하면 "시스템 종료 항목 및 실행 레벨 변경 사항"이 표시됩니다.

여기서 CentOS 7에서 실행 -R했으며 호스트 이름 / 커널 버전 열을 억제하는 옵션 도 전달했습니다 . 또한 관심없는 루트 로그인을 제거했습니다.

# date ; last -x -F -R
Mon Nov 12 01:10:44 UTC 2018
root     pts/0        Mon Nov 12 00:02:57 2018   still logged in
runlevel (to lvl 3)   Sat Nov 10 17:57:29 2018 - Mon Nov 12 01:10:44 2018 (1+07:13)
reboot   system boot  Sat Nov 10 17:57:12 2018 - Mon Nov 12 01:10:44 2018 (1+07:13)
runlevel (to lvl 3)   Sat Oct 27 17:58:20 2018 - Sat Nov 10 17:57:29 2018 (13+23:59)
reboot   system boot  Sat Oct 27 17:58:03 2018 - Mon Nov 12 01:10:44 2018 (15+07:12)
runlevel (to lvl 3)   Sat Jul 21 18:14:55 2018 - Sat Oct 27 17:58:20 2018 (97+23:43)
reboot   system boot  Sat Jul 21 18:14:16 2018 - Mon Nov 12 01:10:44 2018 (113+06:56)
runlevel (to lvl 3)   Sun Nov 12 22:36:14 2017 - Sat Jul 21 18:14:55 2018 (250+19:38)
reboot   system boot  Sun Nov 12 22:35:35 2017 - Mon Nov 12 01:10:44 2018 (364+02:35)
root     pts/0        Fri Nov 10 07:13:20 2017 - crash                    (2+15:22)
runlevel (to lvl 3)   Sun Aug 27 04:15:56 2017 - Sun Nov 12 22:36:14 2017 (77+18:20)
reboot   system boot  Sun Aug 27 04:14:59 2017 - Mon Nov 12 01:10:44 2018 (441+20:55)
runlevel (to lvl 3)   Mon Aug 14 00:14:01 2017 - Sun Aug 27 04:15:56 2017 (13+04:01)
reboot   system boot  Mon Aug 14 00:13:46 2017 - Mon Nov 12 01:10:44 2018 (455+00:56)

위의 6 개의 "재부팅"라인에는 현재 시간과 동일한 로그 아웃 시간이 있습니다.

shutdown system down  Fri Aug 11 08:05:29 2017 - Mon Aug 14 00:13:46 2017 (2+16:08)
root     pts/0        Fri Aug 11 08:05:23 2017 - down                      (00:00)
runlevel (to lvl 3)   Fri Jun 30 07:05:42 2017 - Fri Aug 11 08:05:29 2017 (42+00:59)
reboot   system boot  Fri Jun 30 07:05:27 2017 - Fri Aug 11 08:05:29 2017 (42+01:00)
[...]
root     pts/0        Fri Jun 30 05:48:16 2017 - crash                     (01:17)
root     pts/0        Tue Jun 27 04:59:56 2017 - Tue Jun 27 05:00:30 2017  (00:00)
root     pts/0        Mon Jun 26 11:20:57 2017 - Mon Jun 26 04:24:39 2017  (-6:-56)
runlevel (to lvl 3)   Mon Jun 26 11:15:13 2017 - Fri Jun 30 07:05:42 2017 (3+19:50)
reboot   system boot  Mon Jun 26 11:14:57 2017 - Fri Aug 11 08:05:29 2017 (45+20:50)
root     pts/0        Sun Jun 25 14:07:51 2017 - crash                     (21:07)
[...]
root     tty1         Thu Jun 22 13:07:42 2017 - crash                    (3+22:07)
runlevel (to lvl 3)   Thu Jun 22 13:07:07 2017 - Mon Jun 26 11:15:13 2017 (3+22:08)
reboot   system boot  Thu Jun 22 13:06:51 2017 - Fri Aug 11 08:05:29 2017 (49+18:58)
root     pts/0        Thu Jun 22 12:43:56 2017 - crash                     (00:22)
runlevel (to lvl 3)   Thu Jun 22 12:30:53 2017 - Thu Jun 22 13:07:07 2017  (00:36)
reboot   system boot  Thu Jun 22 12:30:38 2017 - Fri Aug 11 08:05:29 2017 (49+19:34)
root     pts/1        Thu Jun 22 12:26:49 2017 - crash                     (00:03)
root     pts/0        Thu Jun 22 11:55:28 2017 - crash                     (00:35)
runlevel (to lvl 3)   Thu Jun 22 11:49:53 2017 - Thu Jun 22 12:30:53 2017  (00:41)
reboot   system boot  Thu Jun 22 11:49:14 2017 - Fri Aug 11 08:05:29 2017 (49+20:16)

위의 5 개의 "재부팅"라인은 모두 "종료 시스템 종료"시간과 동일한 로그 아웃 시간을 갖습니다.

shutdown system down  Thu Jun 22 11:47:45 2017 - Thu Jun 22 11:49:14 2017  (00:01)
[...]
runlevel (to lvl 3)   Wed Jun 21 15:59:42 2017 - Thu Jun 22 11:47:45 2017  (19:48)
reboot   system boot  Wed Jun 21 15:59:27 2017 - Thu Jun 22 11:47:45 2017  (19:48)

"재부팅"로그 아웃 시간이 "종료 시스템 종료"시간과 다시 일치합니다.

shutdown system down  Wed Jun 21 15:57:58 2017 - Wed Jun 21 15:59:27 2017  (00:01)
root     pts/0        Wed Jun 21 14:27:43 2017 - down                      (01:30)
[...]
runlevel (to lvl 3)   Tue Jun 20 17:14:15 2017 - Wed Jun 21 15:57:58 2017  (22:43)
reboot   system boot  Tue Jun 20 17:14:00 2017 - Wed Jun 21 15:57:58 2017  (22:43)

위와 같이.

위의 결과에서 의사 사용자 "재부팅"에 대해 명시적인 로그 아웃 시간이 기록되지 않는다고 가정하므로 last다음 "종료 시스템 부팅"의 로그 아웃 시간 또는 "종료 시스템 부팅이없는 경우 현재 시간" "를 따르십시오.

"runlevel (to lvl 3)"항목은 로그 아웃 시간이 더 현명한 것으로 보이지만 충돌을 고려하지는 않습니다.

맨 페이지에서 마지막 열은 세션 시작, 중지 시간 및 세션 기간 인 것으로 보입니다.

서버 공급자가 서버를 재부팅 할 때 (최근 Meltdown 및 Specter CPU 취약점을 패치하기위한 예약 된 작업) 작업의 실제 다운 타임은 무엇인지 찾고있었습니다.

"마지막 재부팅"에 대한 대안을 사용합니다. 이미 알고있는 것처럼 명확하지 않기 때문입니다.

실행 tuptime -l나는 시스템 동작의 다음과 같은 목록을 볼 수 있습니다 :

...
Startup:  26  at  06:51:32 AM 11/06/2017
Uptime:   72 days, 20 hours, 5 minutes and 15 seconds
Shutdown: OK  at  02:56:47 AM 01/18/2018
Downtime: 18 minutes and 44 seconds

Startup:  27  at  03:15:31 AM 01/18/2018
Uptime:   5 days, 7 hours, 11 minutes and 32 seconds

특정 시간과 날짜 "02:56:47 AM 01/18/2018"에 시스템 종료 절차에 따라 shudown이 완료되었음을 알 수 있습니다. 가동 중지 시간은 "18 분 44 초"이며 시작 시간은 "03:15:31 AM 01/18/2018"이며 지금은 여전히 ​​실행 중입니다.

마지막 라인 가동 시간. 내가 생각하는 마지막 두 열 재부팅 시간과 현재 시간. 마지막 명령을 실행하면 뒤에서 두 번째 열이 현재 시간을 표시하고 항상 변경되기 때문입니다.