UNIX for Beginners Questions & Answers

My AIX-based accounting program runs an end-of-day process that requires all users to be logged out. Sometimes I have a user that leaves for the day and forgets to logout. Is there any way I can cleanly log a user out without killing their process?

No. Logging a user out means that their login shell has been terminated. If the user used nohup to start jobs that they wanted to continue running after they were logged out, killing off all of their terminal sessions might not be a big deal; otherwise any jobs that they started and hoped would run through the night will also be killed if you terminate their login sessions.

I am not quite sure what you mean with "cleanly". To log a user out the classical method is to terminate (that is: use the kill-command to send a SIGTERM signal to the process) the login shell of this user.

Note, that you use SIGTERM (kill -15) rather than SIGKILL (kill -9). Signal 15 tells the process to kill itself (after reasonably cleaning up) and well-behaved processes do exactly that: they clean up their stuff - temporary files, inter-process communication facilities, forked children, etc. - and then quit.

Only ill-behaved (read: badly programmed programs) processes or ones in real deep trouble (deadlocks, ...) ignore this signal and have to be killed with signal 9, which is not a real signal but a command to the OS to kindly purge the process from existence without giving it any chance of intervention.

To log out a certain user without any detriment to the OS do the following:

Code:

ps -o pid='' -u <username> | while read PID ; do
     kill -15 $PID
done

This will take care even of the processes started with nohup.

For a list of users logged in use:

Code:

who | cut -d' ' -f1 | sort -u

I hope this helps.

bakunin

I will note that kill -9 won't hurt the OS. But, it may leave files partially updated, may leave locks locked, may leave anything that a process was working on partially done. All of those issues may also affect processes killed by kill -15; but at least processes killed by kill 15 have a chance to catch the signal, clean up the state of anything that hasn't been completed, and exit normally. But, arbitrarily logging out users and killing the jobs they were running (especially the job that had been running for 10 hours and would have successfully finished if allowed to run 5 more minutes, but will need to run for another 10 hours and 5 minutes since it was killed) is a sure way to have irate users banging on your desk the next morning.

Note also that you can get the list of users currently logged in without needing the cut command in the pipeline with just:

Code:

who | sort -k1,1 -u

Yes, but only in principle. If a process has allocated a lot of shared memory which it *should* free on exit but won't (because it is killed with signal 9) that may not be hurtful for the OS directly but it definitely will make the runtime stability of the system deteriorate. My bad for not articulating that more specifically.

Like above: yes and no. You are right if we operate a classical Unix system, but in the industry this is rarely the case. Most companies have either specialised non-personal users for this sort of jobs which could easily be excluded from the general purge i proposed - it was just a general suggestion on how to do it - or have job schedulers in place. Typical IBM shops (it was mentioned they run AIX, which is IBMs Unix) are coming from the host and most have an (or even several) IBM mainframe(s) along with AIX, many have Linux too (on x86- as well as POWER-platforms) and Windows servers. In such a diverse environment you don't use cron as a scheduler but something more platform-independent: Control-M from BMC, for instance (but also UC4 and many others).

This in turn means: if a user has a running process he shouldn't have it run anyways and it can be killed for convenience at any time.

About the superfluous cut: yes, you are right. Point taken.

I hope this helps.

bakunin