- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: Check Point Gateway CLI Uptime vs last reboot ...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Check Point Gateway CLI Uptime vs last reboot command output Not Matched (Doubt)
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.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does either match with the "cpd" start time reported by "cpwd_admin list"?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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]#
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What @Bob_Zimmerman told you is 100% how it works and the actual solution to your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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]#
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Which JHF and is your NTP sync working?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Team
JHF : Take 84 (latest one) and our ntp servers are in sync is working
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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: