From owner-freebsd-hackers Sun Dec 1 20:58:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA00630 for hackers-outgoing; Sun, 1 Dec 1996 20:58:36 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA00609 for ; Sun, 1 Dec 1996 20:58:32 -0800 (PST) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id UAA25227 for ; Sun, 1 Dec 1996 20:03:55 -0800 (PST) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.8.2/8.6.9) id PAA05382; Mon, 2 Dec 1996 15:02:25 +1100 (EST) Message-ID: Date: Mon, 2 Dec 1996 15:02:24 +1100 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: freebsd-hackers@FreeBSD.ORG Subject: Logging ttys off X-Mailer: Mutt 0.50 Mime-Version: 1.0 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm looking for a "foolproof" way of logging out lines that are in use. The only real information available at the time I need to do this is the user's utmp entry. The problems I'm having are: - I don't have the process id of the process group leader (unlike SYSV, unforuntately BSD's utmp doesn't provide this) - the serial port may not be accessible, even by root, if the port is in ppp/slip mode. - even if the serial port can be opened, setting the input/ output speeds to B0 does not reliably kill the line (is this an error? should it?). It seems to work on serial lines without clocal set, but not otherwise - I would have expected a hangup on the port regardless (seems to work reliably in other UNIXes I've worked with in the past). So, I'm back to looking for the pid of the process group leader so I can kill it with SIGTERM/SIGKILL. One option that occurs to me is to look at /proc (is the proc filesystem more or less mandatory now?), and attempting to find processes owned by the user, and building a tree of processes to find out which ones were initiated from a particular login (with the advantage of being able to optionally sweep out background processes that would not otherwise die with the process leader). Since I haven't yet looked at this in depth, I'm not even sure if this is a viable solution. I haven't even considered digging this info out of /dev/kmem yet, and since that style of solution seems to be depreciated in any case, that's one path I'd definitely prefer to avoid, especially if this is likely to lead to kernel version dependancies (like ps). Since I'm sure to be reinventing the wheel in doing this, has anyone else ever needed to do something similar? And *please* don't suggest spawning ps and examining its output. :-) Any other suggestions welcome. I did look at source for a couple of idle logout daemons, but both of them used the "set port speed to 0" method, but as I said, this doesn't work reliably enough, nor can I restrict what I'm working on to use with dialup lines only. Regards, David Nugent, Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@blaze.net.au http://www.blaze.net.au/~davidn