I have a client project that is implemented to several different stations and users. When the user logs in, I check to see if any client sessions are open with the user logged into using
userLoggedIn = len(system.util.getSessionInfo(uname))>0
Every once in a while a client will go dormant, and when the connection is restored/refreshed, whatever dormant actual means, the gateway will show 2 clients open to this station. This keeps the user from being able to log in, because the dormant session is still “running.” Any ideas on how to mitigate this, or to automatically close out dormant clients on the gateway?
I still need a solution, or at least some more details about this. If a running client has a connection interruption the client will become dormant. Once the connection is back up, the client connects with a new session. The old session remains open and shows as dormant in the gateway. If a user is logged in during connection loss, the dormant client still shows as logged in. This will prevent them from logging into the current client.
I fail to understand why Ignition won’t terminate the dormant client automatically once the network connection is restored. I left a couple of dormant client session open to see if they would eventually close but over 24 hours later, they are still there.
It’s not preventing actual login to the client, right? Just interfering with your custom startup script? Consider having the startup script broadcast a “kill yourself” message to any conflicting clients and just carry on. A client message handler in any non-dormant connections would cut off any truly conflicting activity. Dead connections that don’t get the message aren’t interfering anyways.
This particular project has a custom login screen that is navigated to using autologin credentials, so no, the fresh client is not blocked from the autologin process. I have the clients setup so they cannot be closed or minimized without a password because I don’t want employees screwing around on the Pi. The active client will open on top of the dormant client. Therefore, I have to manually terminate the client from the gateway which is the easiest method without a script like you mentioned.
There is a catch to the termination script that could be used on my startup script which is a switch user function. These clients are open at workstations. There should always be one client open at each station. If one station goes down, the user will move to an empty station to continue work. I check for current login info to prevent the user from logging into two stations at once.
If I use a terminate script for dormant client kill, it would also do that when they forget to log out of their previous station. This would lead to a station having no client running which would open the pi up to be messed with. As far as I can tell, the getSessionInfo does not include the activity of that session, so how would I distinguish between the accidental double login attempt and the dormant client event?
Consider launching your Pi client as a formal Xsession using a auto-login display manager, with re-login turned on. Any kill of a client will simply restart X with a new one.
Could you check in your startup script for previous sessions and kill them then?
We use this code to do that. We prompt the user, but you could just kill it automatically.
# Check to see if there is already an Ignition client open on this PC. Trying to cut down on multiple clients open on one machine.
projName = system.util.getProjectName()
hostName = system.tag.read("[System]Client/Network/Hostname").value
sessionInfo = system.util.getSessionInfo()
rowIndex = 0
clientCount = 0
for row in sessionInfo:
if sessionInfo[rowIndex][1] == projName and sessionInfo[rowIndex][2] == hostName:
clientCount += 1
if clientCount > 1:
if system.gui.confirm("There is already a client open on this PC, do you want to close this client?", "Client Already Running"):
system.util.exit()
break
rowIndex += 1
@MMaynard
I’ve experimented with this type of code, but didn’t get it working completely yet. Here is the thing, if I loose network connectivity and the current client goes dormant, when the connection comes back another session is opened. This new session will be killed and the dormant one will be left. Once dormant, I’m not sure if it will still be usable?
I’m baffled at why Ignition would not auto terminate the dormant client or at least ignore it as not a valid session. They are counted as opened clients on the gateway
@pturmel
I don’t follow on how to implement that
Here is my initial code that I haven’t fully tested yet for limiting one client session
# Do not allow more than one client per station
host = system.net.getHostName() #host computer name
count = 0
sessions = system.util.getSessionInfo(None,'Sewing Station') #get all open sessions
for session in sessions:
if host == session[2] and not session[3]: # if session host = computer name and is not a designer
count += 1 # tally the count
if count > 1:
system.util.exit(1) # close client without password
break
@dkhayes117 did you ever figure out why you were getting dormant sessions and how to fix this? I’m running into a very annoying issue where every day when users log into a session, I see a considerable jump in CPU usage (from 5% to 10% increase). After a few days, the gateway CPU usage is at 100%, gateway locks up, and we need to do a gateway restart, which takes about an hour. Its a damn waste of time and we’re at the point where we reboot about every third day.
I only noticed yesterday that the considerable jumps in CPU usage happen around shift change or when people come in in the morning. This could be a coincidence, but I have a theory that sessions aren’t being completely released (my terminology is probably off here).
I’m already in contact with support, I’ve received some generic information about alarm status tables and the like, but haven’t gotten to anything concrete yet. What you’re describing above seems to fit my situation - new sessions are being launched but the old ones stick around. One of the support techs said that we have a large number of sessions open even though the gateway webpage says there’s around 50 at any given time (all valid users / workstations).
I’m building a dashboard right now to log and consolidate as much information as possible. For instance, I’m saving CPU and memory usage to Historian (since yesterday) and I’m hoping to be able to correlate user logins, projects, and any CPU abnormalities.
The dormant client issue I had never caused any gateway issues and never consumed any more gateway resources that I could tell. The pain point was I only allow the user to be logged into one station at a time. When the client went dormant, the user stayed logged in so the new session wouldn’t allow them to login. The issue stemmed from the client computer losing networking for long enough for the client to become dormant. When the networking came back up after the client went dormant, the dormant session stayed “open” and a new session showed up on the gateway webpage.
This didn’t happen very often at all since I went back on a couple of computers and replaced the ethernet connectors that weren’t crimped very well. It still happens (on v7.9) occasionally, but I’m currently switching to v8.1. Other than networking disconnects, I have no issue with dormant sessions.
@dkhayes117 Thank you for that clarification. I’m gonna continue working on support with this!
1 Like