I am getting the above message logged in the /usr/adm/messages file. On one of the servers, it seems that as the additional user logs in, an original user is kicked out.
Sorry, not much of an idea, but does your application control the number of sessions which can be active at one time? One of ours does and if a user fails to logout properly, defunct sessions hang around and prevent others from logging in until they are cleared. Seems a bit odd, though, that existing users are being thrown off in preference to new ones being disallowed in your case.
Thanks for the reply. Our application uses an interpreter which links to a license manager. This does keep track of the number of licenses used. What is happening as well is that processes appear when doing a 'ps -ef', but not when doing a 'who'. These processes take up application licenses and cause our users untold irritation.
Dave, when doing a ps -ef are they displayed as <defunct>? If they are, a reboot is possibly (others might know differently) the only remedy. Longer term, your suppliers should address the issue, perhaps.
If they're not defunct, presumably they're still doing something?
When you see these "lost processes" doing the ps -ef command, what is their parent PID? We've had to run scripts that look for such occurances, and usually the PPID will be "1", and the associated terminal will just be ???.
In any case, I agree with Ken that it would be very odd to have an existing process killed automatically when a new user (which exceeds the license count) tries to log in.
Most Application License mgr's have their own utility to show how many licenses are active, and to whom they are assigned. Look for a utility in the License Manager's directory. A commonly used manager is FlexLM, and it uses lmutil.
Yes! The PPID is 1. The term ID is ttypx, though. The process is running, although not necessarily doing anything. Would a script to kill these processes run every minute be the only way to get rid of them? It just seems like a bit of a crappy way to solve the problem.
Dave. Exactly. Have you tried killing such a process? Does it work? In my experience the only way to kill these is a reboot, which again is a crappy way of organising things. Hopefully yours will disappear with a kill. Two possibilities for a permanentish solution:
1. Ask your supplier to look into it.
2. Educate your users to log off properly (though this won't necessarily work if the application is faulty).
Ken, I have checked with my supplier and they can't help. They did say they could contact SCO with the problem though. I think I will get a script going as an interim measure and contact SCO to see what they suggest.
Thanks for all your help...I just want to check one thing. Below I have extracted part of the messages file. I get lost links as well at different times. Do you think these two problems are linked?
WARNING: User login limit exceeded by 2 users
Fri Jan 14 14:43:16 2005
WARNING: User login limit exceeded by 1 user
Fri Jan 14 23:59:40 2005
WARNING: eeE[0] - Lost Link
Sat Jan 15 00:00:20 2005
WARNING: eeE[0] - Lost Link
Sat Jan 15 00:02:36 2005
WARNING: eeE[0] - Lost Link
Sat Jan 15 00:02:53 2005
WARNING: eeE[0] - Lost Link
Sat Jan 15 00:05:47 2005
WARNING: eeE[0] - Lost Link
Sat Jan 15 00:06:02 2005
WARNING: eeE[0] - Lost Link
The two symptoms are very likely related. You should troubleshoot the "Lost Link" errors. Try a different cable and a different hub/switch location. If those don't help, maybe a different NIC for the SCO box.
Until then, you'll need to monitor for those lost processes by running a simple cron script every 5 minutes or so. You can also likely modify the application's lead-in script to monitor itself and die when it's PPID becomes "1".
I had a similar problem on a different server running the same app and the same version of SCO. It may be that the apps binaries are not 100% correct for the OS. Be that as it may, I wrote a script to run every 10 minutes to kill instances of the app with a PPID of 1. (This was suggested by some guys in this forum, btw) It is working quite nicely. This other server is alos reporting lost links.
What script would you suggest I run to monitor the lost links?
You can monitor for the symptom by watching the /usr/adm/syslog and/or /usr/adm/messages. But what you really need to do is fix the problem, not just watch for it. It won't be too long before somebody gets kicked out of the application at a bad time (like during some critical update or purge, or something). The application might not be written in a manner where it can self-protect the integrity of the data. A "lost link" message should be a rarity.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.