Solved: Re: Check Point Gateway CLI Uptime vs last reboot ...

Bulu_N · ‎2023-02-10

Hi Checkmates,

Now As per my understanding : Uptime refers to the amount of time that a system or device has been running continuously without any disruptions or shutdowns AND last reboot >> refers to the time and date when a system or device was
last shut down or restarted.

We need to troubleshoot if reboot happen then because currently no impact.

Bob_Zimmerman · ‎2023-02-11

Again, that’s the date your wtmp was rotated. Run ‘last’ by itself. That will show you what it actually does, which is not what you seem to think it does. It doesn’t tell you when the last reboot was. It tells you when the user ‘reboot’ last did something.

View solution in original post

Chris_Atkinson · ‎2023-02-10

Does either match with the "cpd" start time reported by "cpwd_admin list"?

CCSM R77/R80/ELITE

PhoneBoy · ‎2023-02-10

You're misreading the output of last reboot.
Compare with the results on my lab system:

[Expert@R8120:0]# last reboot
reboot system boot 3.10.0-1160.15.2 Wed Feb 1 01:02 - 19:26 (9+18:23)
reboot system boot 3.10.0-1160.15.2 Tue Jan 17 14:31 - 19:26 (24+04:54)
reboot system boot 3.10.0-1160.15.2 Mon Dec 5 16:55 - 19:26 (67+02:30)
reboot system boot 3.10.0-1160.15.2 Tue Nov 22 18:12 - 19:26 (80+01:13)
reboot system boot 3.10.0-1160.15.2 Tue Nov 22 20:27 - 18:12 (-2:-15)

wtmp begins Tue Nov 22 20:27:13 2022

Clearly, my system has been rebooted.
Your system does not appear to have been, based on the output you've provided.

Bob_Zimmerman · ‎2023-02-10

This points to the issue.

The 'last' command allows you to specify a username to look for. It shows any of that user's events in /var/log/wtmp by default. You can step back through earlier wtmp files using last -f /var/log/wtmp.1, wtmp.2, and so on. Add the 'reboot' username to the end of that, and you get the reboots in that file:

[Expert@DallasSA]# last reboot

wtmp begins Tue Feb  7 16:43:13 2023
[Expert@DallasSA]# last -f /var/log/wtmp.1 reboot
reboot   system boot  3.10.0-957.21.3c Tue Feb  7 16:36 - 04:13 (3+11:36)   
reboot   system boot  3.10.0-957.21.3c Mon Jan  9 17:35 - 16:35 (28+22:59)  
reboot   system boot  3.10.0-957.21.3c Fri Dec 30 22:12 - 17:34 (9+19:22)   
reboot   system boot  3.10.0-957.21.3c Wed Dec 28 23:02 - 22:10 (1+23:08)   
reboot   system boot  3.10.0-957.21.3c Thu Dec 22 18:03 - 22:10 (8+04:07)   

wtmp.1 begins Tue Dec 13 22:30:41 2022

If 'last reboot' prints only when wtmp started, that means the system has not been rebooted since then.

the_rock · ‎2023-02-10

Based on below, times match 100%:

[Expert@LAB:0]# uptime

21:18:29 up 35 days, 4:45, 3 users, load average: 0.13, 0.25, 0.34

[Expert@LAB:0]# last reboot

reboot system boot 3.10.0-957.21.3c Fri Jan 6 16:33 - 21:18 (35+04:45)

wtmp begins Mon Nov 28 19:26:36 2022

[Expert@LAB:0]#

Bulu_N · ‎2023-02-11

@Bob_Zimmerman @the_rock @PhoneBoy @Chris_Atkinson Thank you very much for the response.

Please help I need both output meaning in a simple way.

find the "cpwd_admin list" output

According to this its 44 days which is OK.

But Its showing 9 FEB but I taken on 10 FEB so its looks wtmp begin in 9 FEB.

Bob_Zimmerman · ‎2023-02-11

Again, that’s the date your wtmp was rotated. Run ‘last’ by itself. That will show you what it actually does, which is not what you seem to think it does. It doesn’t tell you when the last reboot was. It tells you when the user ‘reboot’ last did something.

the_rock · ‎2023-02-11

What @Bob_Zimmerman told you is 100% how it works and the actual solution to your question.

the_rock · ‎2023-02-11

@Bulu_N ...k, just to clarify what @Bob_Zimmerman said, so hopefully you wont be confused. Keep in mind, last is really Linux command, not Gaia, but because Gaia is based on Linux, it works the same way. So here, have a look at below and see the difference. So, if you ran for example last admin, it will show you all the activities ONLY from admin account...if I run on the firewall last andy, it will show same but ONLY for account andy. If I run last | grep reboot, it will show LAST reboot. Please see examples below...happy to clarify if you are still confused.

Andy

[Expert@LAB:0]# last
andy pts/2 172.16.10.10 Sat Feb 11 12:46 still logged in
andy pts/2 172.31.9.6 Fri Feb 10 23:19 - 23:21 (00:01)
tjiang pts/3 Tue Jan 31 21:27 gone - no logout
andy pts/3 Tue Jan 31 21:27 - 21:27 (00:00)
andy pts/2 172.31.9.6 Tue Jan 31 21:20 - 21:29 (00:09)
admin pts/2 66.225.157.66 Tue Jan 31 18:41 - 18:42 (00:01)
andy pts/2 172.31.9.6 Thu Jan 26 09:33 - 10:11 (00:37)
admin pts/2 64.201.165.197 Mon Jan 23 19:52 - 19:59 (00:07)
admin pts/2 64.201.165.197 Wed Jan 18 17:52 - 17:53 (00:01)
andy pts/2 172.31.9.6 Mon Jan 16 14:16 - 14:51 (00:35)
andy pts/2 172.16.10.8 Thu Jan 12 23:44 - 23:44 (00:00)
andy pts/2 172.16.10.8 Thu Jan 12 23:43 - 23:44 (00:00)
andy pts/2 172.31.9.6 Thu Jan 12 21:39 - 21:39 (00:00)
andy pts/2 172.16.10.57 Thu Jan 12 19:29 - 19:30 (00:00)
andy pts/2 172.16.10.16 Wed Jan 11 20:32 - 20:32 (00:00)
admin pts/2 66.225.157.66 Wed Jan 11 12:10 - 12:11 (00:00)
andy pts/2 172.16.10.55 Tue Jan 10 23:57 - 23:58 (00:00)
admin pts/2 66.225.157.66 Tue Jan 10 14:13 - 14:14 (00:01)
andy pts/3 172.31.9.6 Mon Jan 9 21:17 - 21:19 (00:01)
andy pts/2 172.16.10.2 Mon Jan 9 21:16 - 21:19 (00:02)
andy pts/2 172.16.10.68 Mon Jan 9 15:29 - 15:56 (00:27)
andy pts/2 172.16.10.33 Sun Jan 8 21:38 - 21:38 (00:00)
andy pts/3 172.16.10.105 Fri Jan 6 16:30 - 16:30 (00:00)
andy pts/2 172.16.10.105 Fri Jan 6 16:14 - 18:49 (02:35)
reboot system boot 3.10.0-957.21.3c Fri Jan 6 16:13 - 12:46 (35+20:33)
andy pts/2 70.48.67.240 Fri Jan 6 16:11 - down (00:00)
andy pts/2 Fri Jan 6 16:02 - 16:11 (00:09)
andy pts/2 Fri Jan 6 13:46 - 16:02 (02:15)
andy pts/2 Fri Jan 6 12:25 - 13:46 (01:20)
andy pts/2 172.31.9.6 Fri Jan 6 11:45 - 11:51 (00:06)
andy pts/2 172.16.10.16 Wed Jan 4 14:24 - 14:25 (00:00)
admin pts/2 64.201.165.197 Wed Dec 28 15:12 - 15:14 (00:02)
admin pts/2 64.201.165.197 Wed Dec 21 19:44 - 19:44 (00:00)
admin pts/2 64.201.165.197 Mon Dec 19 17:42 - 17:52 (00:10)
andy pts/2 172.16.10.57 Thu Dec 15 06:58 - 07:00 (00:02)
andy pts/2 172.16.10.21 Wed Dec 14 06:11 - 06:17 (00:05)
andy pts/2 172.31.9.6 Tue Dec 13 19:41 - 19:41 (00:00)
admin pts/2 66.225.157.66 Tue Dec 13 18:05 - 18:07 (00:02)
andy pts/2 172.16.10.62 Mon Dec 12 18:23 - 18:23 (00:00)
andy pts/2 172.16.10.36 Mon Dec 12 07:01 - 07:02 (00:01)
andy pts/2 172.16.10.34 Sun Dec 11 21:59 - 22:00 (00:00)
andy pts/2 172.16.10.31 Sun Dec 11 20:28 - 20:29 (00:00)

wtmp begins Sun Dec 11 20:28:20 2022
[Expert@LAB:0]# last admin
admin pts/2 66.225.157.66 Tue Jan 31 18:41 - 18:42 (00:01)
admin pts/2 64.201.165.197 Mon Jan 23 19:52 - 19:59 (00:07)
admin pts/2 64.201.165.197 Wed Jan 18 17:52 - 17:53 (00:01)
admin pts/2 66.225.157.66 Wed Jan 11 12:10 - 12:11 (00:00)
admin pts/2 66.225.157.66 Tue Jan 10 14:13 - 14:14 (00:01)
admin pts/2 64.201.165.197 Wed Dec 28 15:12 - 15:14 (00:02)
admin pts/2 64.201.165.197 Wed Dec 21 19:44 - 19:44 (00:00)
admin pts/2 64.201.165.197 Mon Dec 19 17:42 - 17:52 (00:10)
admin pts/2 66.225.157.66 Tue Dec 13 18:05 - 18:07 (00:02)

wtmp begins Sun Dec 11 20:28:20 2022
[Expert@LAB:0]# last andy
andy pts/2 172.16.10.10 Sat Feb 11 12:46 still logged in
andy pts/2 172.31.9.6 Fri Feb 10 23:19 - 23:21 (00:01)
andy pts/3 Tue Jan 31 21:27 - 21:27 (00:00)
andy pts/2 172.31.9.6 Tue Jan 31 21:20 - 21:29 (00:09)
andy pts/2 172.31.9.6 Thu Jan 26 09:33 - 10:11 (00:37)
andy pts/2 172.31.9.6 Mon Jan 16 14:16 - 14:51 (00:35)
andy pts/2 172.16.10.8 Thu Jan 12 23:44 - 23:44 (00:00)
andy pts/2 172.16.10.8 Thu Jan 12 23:43 - 23:44 (00:00)
andy pts/2 172.31.9.6 Thu Jan 12 21:39 - 21:39 (00:00)
andy pts/2 172.16.10.57 Thu Jan 12 19:29 - 19:30 (00:00)
andy pts/2 172.16.10.16 Wed Jan 11 20:32 - 20:32 (00:00)
andy pts/2 172.16.10.55 Tue Jan 10 23:57 - 23:58 (00:00)
andy pts/3 172.31.9.6 Mon Jan 9 21:17 - 21:19 (00:01)
andy pts/2 172.16.10.2 Mon Jan 9 21:16 - 21:19 (00:02)
andy pts/2 172.16.10.68 Mon Jan 9 15:29 - 15:56 (00:27)
andy pts/2 172.16.10.33 Sun Jan 8 21:38 - 21:38 (00:00)
andy pts/3 172.16.10.105 Fri Jan 6 16:30 - 16:30 (00:00)
andy pts/2 172.16.10.105 Fri Jan 6 16:14 - 18:49 (02:35)
andy pts/2 70.48.67.240 Fri Jan 6 16:11 - down (00:00)
andy pts/2 Fri Jan 6 16:02 - 16:11 (00:09)
andy pts/2 Fri Jan 6 13:46 - 16:02 (02:15)
andy pts/2 Fri Jan 6 12:25 - 13:46 (01:20)
andy pts/2 172.31.9.6 Fri Jan 6 11:45 - 11:51 (00:06)
andy pts/2 172.16.10.16 Wed Jan 4 14:24 - 14:25 (00:00)
andy pts/2 172.16.10.57 Thu Dec 15 06:58 - 07:00 (00:02)
andy pts/2 172.16.10.21 Wed Dec 14 06:11 - 06:17 (00:05)
andy pts/2 172.31.9.6 Tue Dec 13 19:41 - 19:41 (00:00)
andy pts/2 172.16.10.62 Mon Dec 12 18:23 - 18:23 (00:00)
andy pts/2 172.16.10.36 Mon Dec 12 07:01 - 07:02 (00:01)
andy pts/2 172.16.10.34 Sun Dec 11 21:59 - 22:00 (00:00)
andy pts/2 172.16.10.31 Sun Dec 11 20:28 - 20:29 (00:00)

wtmp begins Sun Dec 11 20:28:20 2022
[Expert@LAB:0]# last reboot
reboot system boot 3.10.0-957.21.3c Fri Jan 6 16:13 - 12:47 (35+20:33)

wtmp begins Sun Dec 11 20:28:20 2022
[Expert@LAB:0]# last | grep reboot
reboot system boot 3.10.0-957.21.3c Fri Jan 6 16:13 - 12:47 (35+20:34)
[Expert@LAB:0]#

syntaxerror · ‎2024-09-24

Dear Team

We observe that the uptime for the management server in the smart console is showing a negative value.

However, when checking the device status, the uptime appears to be accurately reflected.

Chris_Atkinson · ‎2024-09-24

Which JHF and is your NTP sync working?

CCSM R77/R80/ELITE

syntaxerror · ‎2024-09-24

Dear Team

JHF : Take 84 (latest one) and our ntp servers are in sync is working

Bob_Zimmerman · ‎2024-09-24

Uptime is not a normal column in SmartConsole. What is providing that column? I'd guess an extension, in which case you'll need to take a look at how the extension works.

Chris_Atkinson · ‎2024-09-24

If I had to guess we are monitoring a process uptime rather than the OS uptime here, suggest a TAC case.

If you change your selection to the following uptime is an available column:

CCSM R77/R80/ELITE

Are you a member of CheckMates?

Check Point Gateway CLI Uptime vs last reboot command output Not Matched (Doubt)