Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Muhammad_Ali
Participant

Can't Discard "SmartView Tracker" sessions on R80.20 SmartConsole

Is there any way to discard the old "SmartView Tracker" sessions on R80.20 SmartConsole? The only option I get is  "Disconnect" and that is also disabled. Find attached the screen shot below:

Can't Discard SessionCan't Discard Session

whereas I can "Discard" and "Take over" sessions for SmartConsole as shown below:

Can Discard & Takeover SessionCan Discard & Takeover Session

I have gone through the discussion on  https://community.checkpoint.com/t5/General-Management-Topics/clear-disconnected-sessions/td-p/33027  and also followed the scriptable solutions to discard sessions in sk133872 and sk113955 but none of them help.

 

Secondly, when I run the below two commands mentioned on sk133872, I don't even see the active/opened sessions either? I want to get the UID so I can try deleting by using mgmt_cli discard uid UID-NUMBER -r true suggested on sk133872, but I get below output when I run both commands.

Sessions3.jpg

psql_client cpm postgres -c "select applicationname,objid,creator,state,numberoflocks,numberofoperations,creationtime,lastmodifytime from worksession where state = 'OPEN' and (numberoflocks != '0' or numberofoperations != '0');"

AND

psql_client cpm postgres -c "select applicationname,objid,creator,state,numberoflocks,numberofoperations,creationtime,lastmodifytime from worksession where state != 'PUBLISHED' and state != 'DISCARDED' and (numberoflocks != '0' or numberofoperations != '0');"

0 Kudos
11 Replies
Timothy_Hall
Legend Legend
Legend

In the SmartView Monitor GUI, select Disconnect Client under the Gateways menu and see if that works.

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Muhammad_Ali
Participant

In SmartView Monitor GUI, it doesn't show those two "SmartView Tracker" sessions. It is only showing the active sessions.

Sessions4.jpg

0 Kudos
Timothy_Hall
Legend Legend
Legend

For the old-school GUIs you will probably need to look for the original config files that tracked who was logged into them, try looking for the following files on the SMS and editing/removing them:

$FWDIR/conf/clients_info.C

$FWDIR/tmp/manage.lock

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
PhoneBoy
Admin
Admin

SmartView Tracker is deprecated in R80.x.
As such, you can expect no support for SVT sessions in R80.x SmartConsole.
0 Kudos
Dale_Lobb
Advisor

  That may be Checkpoint's official stance on the use of SmartView Tracker, but I would be interested in seeing a count of how many people are still using Tracker to get past deficiencies in the SmartConsole Log View.    My team uses SmartView Tracker on a regular basis, because there are so many issues with SmartConsole Log View, it's pretty much a lost cause for many situations.

  I have also seen the issue with SmartView Tracker session that are disconnected and cannot be discarded form SmartConsole.  

 

  Here is what I found:  Get everyone off the smartconsole, otherwise you have a pile of connections to sort through.  You'll still likely have a pile of connections, but there will be fewer is you have no active admins.  Use this command from the management CLI in expert mode (notice that you are looking for sessions with zero locks and zero changes):

# psql_client cpm postgres -c "select applicationname,objid,creator,state,numberoflocks,numberofoperations,creationtime,lastmodifytime from worksession where state = 'OPEN' and (numberoflocks = '0' or numberofoperations = '0');"

You will see something like this:

applicationname | objid | creator | state | numberoflocks | numberofoperations | creationtime | lastmodifytime
---------------------+--------------------------------------+---------+-------+---------------+--------------------+-------------------------+-------------------------
| f969503c-b76b-4cd3-8914-031f5541000d | System | OPEN | 0 | 0 | 2019-02-09 22:17:34.011 | 2019-02-09 22:29:22.814
| 63675a61-0814-4ef7-84cc-0c59a3092286 | System | OPEN | 0 | 0 | 2019-03-06 01:01:40.528 | 2019-04-02 13:45:41.437
| faefb313-3d08-479e-a671-2d6c296c9ee9 | System | OPEN | 0 | 0 | 2019-03-04 01:01:40.588 | 2019-04-02 13:45:41.468
| c80b1170-751c-4935-ace0-1f2b977b0e40 | System | OPEN | 0 | 0 | 2019-02-10 01:04:40.866 | 2019-04-02 13:45:41.497
| b5dc6e63-84a7-4ac0-bd07-94ef0675b9d1 | System | OPEN | 0 | 0 | 2019-03-13 01:01:42.35 | 2019-04-02 13:45:41.62
| d39af1a2-f23c-4137-ba85-fe53c7c84921 | System | OPEN | 0 | 0 | 2019-03-06 01:01:42.389 | 2019-04-02 13:45:41.547
| 3a462c0b-f51e-4645-b0d0-6362df537759 | System | OPEN | 0 | 0 | 2019-02-14 01:01:42.475 | 2019-04-02 13:45:41.571
| 11339347-0830-4225-8b03-5339ab3902f9 | System | OPEN | 0 | 0 | 2019-03-13 01:01:40.496 | 2019-04-02 13:45:41.642
| 70045b92-8049-411e-8ac4-63114d2c5275 | System | OPEN | 0 | 0 | 2019-03-20 01:01:42.8 | 2019-04-02 13:45:41.347
| cba50b76-cc9e-4ed5-ba74-355b02fbafff | System | OPEN | 0 | 0 | 2019-03-20 01:01:40.505 | 2019-04-02 13:45:41.522
| bb00e6ee-e57c-4c73-bf89-36a098d1e14c | System | OPEN | 0 | 0 | 2019-03-29 01:01:45.06 | 2019-04-02 13:45:41.596
| 14de4986-fc00-4e99-8ca9-982011d35277 | System | OPEN | 0 | 0 | 2019-03-27 01:01:42.459 | 2019-04-02 13:45:41.665
| fc04e7ae-72e2-44d4-a2bb-dd36841b6e29 | System | OPEN | 0 | 0 | 2019-02-14 01:01:40.496 | 2019-04-02 13:45:41.127
| a18385b9-ce58-40ad-bdf6-38c1edf9650b | System | OPEN | 0 | 0 | 2019-02-21 01:01:42.379 | 2019-04-02 13:45:41.218
| c995a7cb-6c6b-4fb5-b58b-01147b8850d2 | System | OPEN | 0 | 0 | 2019-02-21 01:01:40.509 | 2019-04-02 13:45:41.251
| 3bab9a69-4d35-4e4a-8544-17866a04067b | System | OPEN | 0 | 0 | 2019-03-04 01:01:42.678 | 2019-04-02 13:45:41.284
| 5d0f9eb3-93c4-4ef0-ae60-d89e36c4664e | System | OPEN | 0 | 0 | 2019-02-10 01:05:01.476 | 2019-04-02 13:45:41.316
| 55b56913-4407-421d-ad11-ae0c8220e6e8 | System | OPEN | 0 | 0 | 2019-03-29 01:01:46.934 | 2019-04-02 13:45:41.378
| aa2ade54-2e22-4a95-a8c7-6a4cf73b74d7 | System | OPEN | 0 | 0 | 2019-03-27 01:01:40.505 | 2019-04-02 13:45:41.408
log-viewer | 7ed8b8f9-d116-44c5-acc4-f585a608aa9a | <admin name>| OPEN | 0 | 0 | 2019-04-03 09:13:03.229 | 2019-04-03 10:28:17.903
--snip
--

  You're looking for the line with the applicationname "log-viewer".

   Plug the objid from the log-viewer line into the command:

   #  mgmt_cli discard uid <objid> -r true

 

Muhammad_Ali
Participant

Hi Dale_Lobb

Thanks for providing the solution. After running the command, SmartView Tracker sessions have been discarded from SmartConsole and it has resolved the issue.

Dale_Lobb
Advisor

  It has recently come to my attention that orphaned SmartView Tracker sessions can actually have locks, so my previous solution does not work in all cases.

  We recently had a core router issue that resulted in all admins losing connection to our Management system.  This also resulted in some orphaned Tracker sessions.  However, one admin has chosen to save a query in Tracker, which reulted in outstanding locks, so my previously posted psql_client query did not find the session.

  Here is a slightly more robust option:

# psql_client cpm postgres -c "select applicationname,objid,creator,state,numberoflocks,numberofoperations,creationtime,lastmodifytime from worksession where state = 'OPEN';" | grep -iE "applicationname|--------|log-viewer"

  All Tracker sessions are identified by the name "log-viewer", so this query finds them even if they have open locks.  Then they can be discarded:

#mgmt_cli discard uid <objid> -r true

 

cli_sample.jpg

 
0 Kudos
PhoneBoy
Admin
Admin

As a separate thread, we should understand what features are missing in SmartView that compel you to still use SmartView Tracker.
0 Kudos
Dipanjan_Goswam
Explorer

R80.20 Smart log indexes keeps crashing everytime when we are keeping more than 30 days. Initially we had set it to 60 days from that we moved it to 50 then 30 to now it's 10. After every restart it start log indexing back again and consume 4-5x times CPU what we have allocated. Although there is no permformance impact due to lower NI value. but still annoying alomost every other days to fix it and re-run the indexing. This is the only reason, we are using Smart view tracker. Not sure, when this can be fixed.

0 Kudos
PhoneBoy
Admin
Admin

Do you have a TAC case on this?
0 Kudos
Dipanjan_Goswam
Explorer

Hi PhoneBoy,

Yes, ofcourse. We escalted even. We have pretty hi-fi spec (resouces). We are running with MDM (with 10 CMA) R80.20 with T-118 JFHA. They suggested to reduce it to 10 Days for the time being, which makes no sesnse as we have 24 TB storage which can store atleast 50-60 DAYS logs (As per our estate). Not sure why don't they fix the bugs .. So, we reduced it to 10 DAYS, but set normal log retention period to 60 days. hence we use SVT to check whenever require.


Thanks,
Dipanjan

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events