Logon expiration script

[Jarheadatheart]

Guru's,

I am 100% new to HPUX and I don't know where else to turn for this issue.

I have an L class HP-UX 11.11 system, and the logon account I am having issues with is "eipedi".

If I do a who -u, this account has dozens of logons, and it actually locked the system a few weeks ago.

So my question is; Is there a simple script or something that I can run to kill or log off the account session if it is older than 24 hours?

Any help is appreciated.

[James R. Ferguson]

Hi:

You could examine the output of 'who -u' and use the elapsed idle time to decide who's session should be killed if you think this is really a problem.

Whenever you kill something, do it gently first. A 'kill -15' allows a process a chance to cleanup --- remove temporary files, etc. since this signal can be caught. If a simple 'kill' (the default is 'kill -15') doesn't work, you can escalate to a 'kill -9'. A process which ignores this isn't in a state to terminate. It is likely waiting on a pending I/O. In that case, patience or a reboot are your only other option.

It is also possible, particularly on older releases, that the output you see from 'who -u' contains phantom lines. That is, the 'utmps' file which underlies and holds the data you see, is corrupt. In this case you will likely not find a 'pid' on the system that corresponds to the 'pid' in the 'who' output. This will correct itself on the next reboot. After all, I'm sure you periodically patch your servers :-)

Regards!

...JRF...

[Jarheadatheart]

See, that is the odd part, these aren't showing idle times. They have running processes, but they are all performing the same task, and onyl one of them needs to be.

Is there a simple way to limit the logon to only one ssh session at a time? Would that resolve this issue?

[Jarheadatheart]

Upon further review, even though these show on the who -u output, you are correct, the logons aren't really active. The accounts have logged out, but my system isn't seeing that for some reason....

So outside of a reboot, how can I clear these?

[Mel Burslan]

It definitely resolves the issue but doing this is a little off the beaten path. In 11.11 version, there is no system setting that says "this user can not login to more than one session" You need to build this functionality into your /etc/profile, which every user runs upon successful login. It is not hard, but for some cases, it might have some unexpected and unwanted effects.

The main question is, why are there so many instances of this user running ?

Is it because many people decide to do the same thing at the same or close to same time ? If they do, you have big gap in precess definitions. And you need to address it. Multiple people logging in using the same account is very much frowned upon, if you have to go through a security audit.

Is it because, the session starts and never completes successfully ? If this is the case, you need to figure out why and fix that issue.

Is it because it takes too long to process and someone starts it again before the previous completes ? It is again due to a not well crafted process definition.

If you can elaborate a little more, why this is taking place, answers will be more helpful

[James R. Ferguson]

Hi (again):

> Upon further review, even though these show on the who -u output, you are correct, the logons aren't really active. The accounts have logged out, but my system isn't seeing that for some reason....

As I said, this suggests that the underlying 'utmps' file is "corrupt".

> So outside of a reboot, how can I clear these?

Ignore them or reboot.

Regards!

...JRF...

[Jarheadatheart]

Mel,
Looking at the interface partners systems, the account is logging out. and if I try to kill the PID for the SSH session, the pid isn't found.

So given that information I suppose James is correct and it is a corrupted umtp file.

But do I have to reboot to clear this file?

If I simply remove all of the entries in the utmp file for "eipedi", will that remove them from the who -u?

Or a better question is; James, if I ignore these, and they stack up (2 a day are being added) is it going to somehow lock my system from logon?

[James R. Ferguson · Accepted solution]

Hi (again):

> Or a better question is; James, if I ignore these, and they stack up (2 a day are being added) is it going to somehow lock my system from logon?

If they are phantom sessions (i.e. the associated pid truly isn't in the process table) then there is nothing to impede performance or any kernel fence governing the number of processes or open files.

If you are seeing these regularly, it is possible that you have un-educated PC-based emulator connections. Windows users like to "x" the window to close it. Such abortive disconnects do nothing to signal the Unix layer that the connection should be gracefully severed. It is this kind of user behavior that often leads to what you appear to describe. Tell your users to gracefully exit (the application, telnet or ssh session) and then annihilate their emulation window.

Regards!

...JRF...

[Dennis Handly]

>So outside of a reboot, how can I clear these?

You would have to manually edit the utmp* file(s):
-rw-r--r-- 2520 May 16 23:17 /etc/utmp
-rw-r--r-- 8960 May 16 23:17 /etc/utmpx

It may be easier to just ignore them, than for me to explain how. You could look for my replies on this topic?
http://h30499.www3.hp.com/t5/Patches/who-r-without-output-because-of-etc-utmp-is-crap/m-p/4628907#M9604

http://h30499.www3.hp.com/t5/System-Administration/user-id-processes-not-get-killed/m-p/4377388#M348102

http://h30499.www3.hp.com/t5/System-Administration/DTC-port-incorrectly-shows-up-in-ps-command/m-p/4765511#M389455
>JRF: then there is nothing to impede performance or any kernel fence governing the number of processes or open files.

The last time this happened, someone implemented Mel's "limit" police and that user couldn't logon because of the corrupted file.

[James R. Ferguson]

Hi (again):

> Dennis: The last time this happened, someone implemented Mel's "limit" police and that user couldn't logon because of the corrupted file.

Indeed, but that isn't a kernel limitation. Moreover, that may be one (good) way to make sure any Window's user learn how to gracefully logout: if it hurts, don't do it :-)

Regards!

...JRF...

[Jarheadatheart]

James,
You "x" windows sessions was the issue, on the side of our interface partners, and has since been corrected.

Thank you all!