From owner-freebsd-hackers Mon Oct 30 0: 9: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id DE58C37B479 for ; Mon, 30 Oct 2000 00:09:03 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id CAA15540; Mon, 30 Oct 2000 02:12:42 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Mon, 30 Oct 2000 02:12:42 -0600 (CST) From: Ryan Thompson To: andrew@ugh.net.au Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Logging users out In-Reply-To: Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG andrew@ugh.net.au wrote to freebsd-hackers@FreeBSD.ORG: > Hi, > > What is the best way to go about logging a user out given their tty? I had > a couple of ideas: > > (a) open their tty and set the baud rate to 0 Probably wouldn't be very effective. > (b) use tcgetpgrp to get the process group id of the foreground process > group on that tty, then with that info use libkvm to find the session > leader's pid and send it a SIGHUP Why not just kill their controlling shell? That's about all a logout will do, anyway. If they have processes detatched from the controlling terminal, the user typing "logout" will not stop them. Recall that "background" and "foreground" are shell concepts, not properties of any given process. > (c) use tcgetpgrp to get the process group id of the foreground process > group on that tty then using killpg to kill all the members of that > process group. I would need to do this in a loop to catch background > process groups that come to the foreground after a process group is > killed. > > Whenever sending a signal I will have to verify the process exited, > possibly sending TERM and KILL until it does. > > Problems: > > (a) a doesn't seem to work...I'm guessing it only works on serial lines. > > (b) b would be quite unportable I would guess (although thats not a > tragedy I would like to avoid it if it isn't too hard). Also if the > session leader dies is there any guarentee everything else in the session > goes as well? Or would I have to go through and kill every process group > in the session? Never any guarantee.. user programs can set up signal handlers to catch or ignore any signal but SIGKILL. Then again, a user typing "logout" will not clean up absolutely everything, either. > (c) c just seemed to be a bit of a hack (assuming you haven't just read > b). Out of all of them it seems the best so far however. > > Does anyone have any suggestions or comments? Is there a "proper" way to > do this? a) Kill the controlling shell. This will leave some processes behind that are no longer part of the user's session (like programs that have detatched from the terminal and become daemons), and processes that were never part of the user's session (like processes that they started on a different terminal) b) kill - `ps -axo user,pid | grep user | awk '{print $2}'` Kills every process owned by ``user''. Sending SIGKILL does so in a non-catchable way. c) /sbin/halt is pretty much guaranteed to do the trick ;-) > > Thanks, > > Andrew > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Ryan Thompson Network Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message