Terminate an User Session.

[Former Member]

I am trying to terminate a User Session that is several months old. I have tried searching SDN and have not found anything that applies or works. I have also tried using SM04, SM50, and also SM66 to cancel the process, but have been unsuccessful in my attempts. The other problem I have encountered when canceling the process is that a new process is started, going from 2 processes to now 4. We do not have a Basis person as well, and it's been learn as you go and using whatever information I can find. I am using version 4.7. Thanks in advance. If this is not in the correct forum, I ask the moderators to move this post to the appropriate forum as well. I apologize if I have not been more active in the forums, but due to the economy and downsizing I am the only remaining SAP person here and don't have much time to use the forum as in the past.

[Former Member · Accepted solution]

Silly comment: One of the things I'd do immediately is to check where the connection originates (i.e. check originating IP address in SM04 for the user) and what is currently running. Per your comment you have canceled a process in SM50, so it sounds it's not just an open session, something is actually running under that user id. So when you look at the program that is being executed for this user, does this give you any clue? I'm assuming that connection type is GUI and the process you've terminated is a dialog process?! It's highly unlikely (based on what you describe), but in theory there could be another person (ab)using the given user id.

The other part that I don't fully understand is the forking you've mentioned: The other problem I have encountered when canceling the process is that a new process is started, going from 2 processes to now 4. So there's two active processes (dialog?) and when you cancel one you get four? What happens then if you cancel again one of the four, do you now get eight? Sounds a bit odd... (admittedly the whole thing sounds quite odd)

Do you get any feedback when you try to terminate the session from SM04? Have you checked the system log (SM21) to see if there's anything unusual (or for that matter the security audit log in SM20 if your company uses it)? Without any further details I suspect it's more a case for OSS as suggested by Rob (unless somebody else has encountered that phenomenon before).

[Former Member · Accepted solution]

Hi Harold,

I have checked the IP Address from SM04 and it is the correct address for this user. This would lead me to believe the user id is not being abused by someone else.

The process has been running since August 5th, from an ABAP program. The user noticed that the program was running longer than usual so she used the 'Stop Program' from Session Window. The connection type is GUI.

To explain the forking better, I started out with 2 processes running. I tried to kill the process in SM66 and it started another process, giving me 3. I then tried to cancel the process in SM50, and now have 4 process currently running. By trying to kill it again, it should give me 5.

When trying to terminate from SM04, I do not receive any messages. I refreshed the screen and see the processes are still active. I have also looked at the log in SM20 and it is empty, the log in SM21 for the dialog process shows an error message that says 'Assurance in Too may DB-rows in Program $Id: //b001 ??????????? Location ???.

[Former Member · Accepted solution]

Hhmm, weird. I'd probably try to take a peek at what the processes are actually doing, but that probably doesn't really help. The odd part is that re-spawning aspect that I haven't heard of yet for GUI connections. It would be interesting to know if your spawned processes (after your kill attempts in SM50/SM66) correspond to an increase in user sessions (seen in SM04 on the corresponding app server). If not, then maybe you actually have a user "master" process, that simply spawns off some RFC's (so by killing the right process you'd be able to stop this). But even if that would be true, why is it impossible to end the user session via SM04?

To me there's two straws left:

<ol style="list-style:circle">

<li>Apart from the mentioned OSS message you might want to look into moving this problem into a different forum. It's really more of a basis question and thus the general ABAP forum most likely doesn't give you good results. Forum might be more suitable? I'd try to search for some appropriate forum and then possibly ask a moderator to move the thread.</li>

<li>Try to restart the application server and see if that helps (hopefully you can either do that on an emergency basis or have some scheduled maintenance coming up)</li>

</ol>

Good luck with your problem and I'm curious to see a resolution (hopefully somebody has a good answer how to fix this).

[Former Member · Accepted solution]

Thanks Harold. I am going to try restarting the APP server later today or tomorrow. I tried OSS and see that we no longer have a Maintenance Agreement with them, since down sizing and cutting back on expenses, it was decided several years ago that the Maintenance Agreement was not needed as our system has been stable for quite sometime. I will also ask the Mods to move this to a different forum and keep you posted. Thanks for the help and suggestions.

[Former Member · Accepted solution]

Do you want me to move it to ?

Rob

[Former Member · Accepted solution]

Yes, that would be greatly appreciated. I have already hit the Abuse button to ask for it to be moved. Thanks for your help Rob.

[Former Member · Accepted solution]

Moved.

Rob

[Former Member · Accepted solution]

Hmmm... interesting...

My battle-plan would be to use Sm19 to activate a dynamic filter on the user for all events (particularly system and RFC calls and logins). You can do this even if the log is inactive (RZ11 -> rsau/enable ) but the filter will be kicked out again when you restart the system.

From there follow the procedure described in SAP Note 495911 to find out what is going on at runtime in the developer trace.

To lean out the window...:-) I suspect that it is an external server program which is still running and is buggy to process something. Possibly the GUID function is not performing an existance check and then re-creating the session from the operating system and attempting to process previous session related data again but the program ID for the data which isn't there. Consider yourself lucky that it is not blocking all workprocesses...

If my guess is correct and there is nothing obvious in ST22, then in transaction SMGW there are also "expert" tracing options to track this down, but be carefull of which one you turn on in a production system. Via the menu you can find them. Search for the option "external security --> logging". It is not very intuitive... The option "Trace up" and "Trace down" is certainly wrong as it will increase the dev trace for all users without telling you which level it is on. (sorry, posting from memory).

Cheers,

Julius

ps: Before using transaction SMGW with "basis" type authorizations, you must read the documentation on the functions!

Edited by: Julius Bussche on Oct 27, 2010 12:06 AM

[JPReyes · Accepted solution]

Hi Mike,

Seems like your session got stuck in Limbo. What I will try to do is to kill the PID.

First check if theres any update errors (I presume its clean as you would have notice them in the last 2 months)

I started out with 2 processes running. I tried to kill the process in SM66 and it started another process, giving me 3. I then tried to cancel the process in SM50, and now have 4 process currently running. By trying to kill it again, it should give me 5.

Have you checked if the PID's exist at OS level?... If they do then your can use kill -9 to remove them.

You could try 100 different things but I think the best will be to find a suitable time to bounce the instance.

Regards

Juan

[Former Member · Accepted solution]

I had the same issue and what I have done is in SM04 --> select the user, from user menu --> logoff user systemwide.

If this doesnt help then follow Juan's suggestion.

[Former Member · Accepted solution]

Thanks everyone for your input, it was greatly appreciated and offered a good learning experience. I did stop the App Server and Restarted it. The Processes are no longer there. Thanks again.

[Former Member · Accepted solution]

Awwww.... now we will never know....

We have similar problem question in the Security Forum at the moment. Let us know if it returns after the restart?

Reference -->

Cheers,

Julius

PS: If you take a look directly into table SNAP for this issue, is there any related information from way back when?

Edited by: Julius Bussche on Oct 27, 2010 11:18 PM

[Former Member · Accepted solution]

After restarting the App server, the Extra Dialog Processes were cleared and no longer appear in SM50, SM66, or SM04. I did check the SNAP table for when this did occur and found no entries for the user or just for the date range as well.

Thanks again.

[Former Member · Accepted solution]

I linked this thread to the other one, so perhaps it will also just "go away"....

I think it would still have been usefull to find out where the GUI ID was being spawned from, to correct a possible program error. Restarting the system is not a solution for program errors.

Cheers,

Julius

[Former Member · Accepted solution]

The user had tried to cancel a program because she felt it was taking to long to run. This is a report that she runs quite often and has not had any issues running in the past. Could have been the system was slow that day, or she try to cancel it for other reasons. I do agree that shutting down the App server is not good practice for a program error.

[kesavadas_thekkillath]

Ignore

[Former Member]

Is there any set time after which a stuck SAP session would end by itself ?

Mona

[_IvanFemia_]

Hi,

seems really strange... Without any knowledge of you system I'll in the following order:

1 - SM04 close session

2 - Change user password or disable the user ID

3 - From SM50 delete the process with core

4 - Check on SM37 if any job is scheduled / released / running

Regards,

Ivan

[Former Member]

I have tried SM04 and SM50 already as noted above. When I cancel with a Core Dump, it opens and adds another session. I have checked SM37 and there are no scheduled/released/running jobs for this user for the date range and Program Name.

[_IvanFemia_]

Disable USERID and check again

Ivan

[Former Member]

I have tried locking the account and the processes are still running.

[Former Member]

If you log on under that userid, it should ask you if you want to terminate the existing sessions.

Rob

[Former Member]

The user has been selecting to terminate any open sessions each time she logs on, but the sessions still do appear in SM66 and SM50. I have deleted the entry from the USR41 table so the user is no longer prompted, since she has been prompted the past several months.

[Former Member]

Does it appear in SM04?

Rob

[Former Member]

Yes, it appears in SM04 and I am unable to end the session from there as well.

[Former Member]

Have you tried sending this to OSS?

However, I suspect they woud lsay either "consulting issue" or "do a restart".

But it doesn't hurt to ask.

Rob

[Former Member]

Thanks Rob, I will try OSS first and feel you may be right. Are you familiar with Keshav's post above using kill.sap?

[Former Member]

No, but Google might help.

Rob

[kesavadas_thekkillath]

Ignore