On Tue, 31 Oct 2000, Terry Lambert wrote:
> (struct tty *)->t_pgrp->pg_id
>
> Which is the process ID of the group leader of the foregroun
> group.
Isn't this what tcgetpgrp returns? Problem with this is that it probably
isn't the PID of the session leader. Wouldn't I need (struct tty
*)->t_s
On Tue, 31 Oct 2000, Terry Lambert wrote:
> not noticing that read was returning 0 (which is returned on EOF,
> but is also returned on perfectly goo non-blocking fds, and in the
If you read from a non blocking fd (and there is nothing to read) don't
you get -1 and errno = EAGAIN?
> case that
On Tue, 31 Oct 2000, you wrote:
> On Tue, Oct 31, 2000 at 01:40:32PM +0100, Thierry Besancon thus spoke:
> > Dixit Bill Vermillion <[EMAIL PROTECTED]> (le Tue, 31 Oct 2000 07:22:55 -0500) :
> >
> > » > % ps -aux | grep username
> > »
> > » > username 1637 1.3 0.7 1340 868 p1 Ds 11.36AM
> > Why not just kill their controlling shell?
>
> I believe that what I'm doing...the "controlling shell" would be the
> session leader. The question is how to get its PID.
Grovel the tty structure using libkvm.
You want to look for:
(struct tty *)->t_pgrp->pg_id
Which is the process ID of t
> > Uh, well, "foolproof" != "calling ps and awk and grep and looking for
> > processes". For ANY definition of foolproof.
> >
> > And it is certainly foolproof from the point of view that there's no way
> > in hell for the session not to be terminated, unlike some ps garbage I've
> > seen.
>
>
Joe Greco wrote:
>
> > > I wrote a little line program to do a revoke(), it was basically
> > >
> > > int main(int argc, char *argv[]) { revoke(argv[1]); }
> > >
> > > Now this doesn't kill a darn thing. And you should be aware of it! But it
> > > does forcibly "close" any open fd's pointing at
> Unfortunatly, sometimes when processes suddenly lose stdin/stdout, they
> jump into infinate loops and start eating cpu cycles like crazy. I'd
> hate
> to see what happens when you kill off a significant number of people
> running
> these poorly behaved programs. FVWM95 Taskbars used to be no
Joe Greco wrote:
>
> > > I wrote a little line program to do a revoke(), it was basically
> > >
> > > int main(int argc, char *argv[]) { revoke(argv[1]); }
> > >
> > > Now this doesn't kill a darn thing. And you should be aware of it! But it
> > > does forcibly "close" any open fd's pointing
> > I wrote a little line program to do a revoke(), it was basically
> >
> > int main(int argc, char *argv[]) { revoke(argv[1]); }
> >
> > Now this doesn't kill a darn thing. And you should be aware of it! But it
> > does forcibly "close" any open fd's pointing at the tty in question, and
> >
> I wrote a little line program to do a revoke(), it was basically
>
> int main(int argc, char *argv[]) { revoke(argv[1]); }
>
> Now this doesn't kill a darn thing. And you should be aware of it! But it
> does forcibly "close" any open fd's pointing at the tty in question, and
> most programs
> 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 Mon, 30 Oct 2000, Ryan Thompson wrote:
> > (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?
I believe that w
[EMAIL PROTECTED] wrote to [EMAIL PROTECTED]:
> 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 t
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
(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
14 matches
Mail list logo
