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

[Muhammad_Ali]

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 Session

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

Can 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.

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');"

[Timothy_Hall]

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

[Muhammad_Ali]

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

[Timothy_Hall]

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

[PhoneBoy]

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

[Dale_Lobb]

  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]

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]

  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

[PhoneBoy]

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

[Dipanjan_Goswam]

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.

[PhoneBoy]

Do you have a TAC case on this?

[Dipanjan_Goswam]

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