[ale] Sessions question

[Lightner, Jeff]

Also sessions typically get pty’s assigned to them so the traffic to and from a session is associated with a given pty.

If you run “who” you’ll see logins with associated device files such as pts/1, pts/2 etc…   Those are assigned starting with the first one each time.  (i.e. If you login first this time you’ll get pts/1 but if someone else logs in first next time they’ll get pts/1.  If you then login second you’d get pts/2.)

You can find children processes associated with a given session by using “ps –ft<device>” such as “ps –ftpts/3”   That is sometimes useful if the user has done an su or sudo because “ps –fu<user>” will show only the user as logged in and not any children that got spawned by doing such an su or sudo.


From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Jim Kinney
Sent: Monday, October 19, 2015 1:51 PM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] Sessions question

It's about PIDs and parents. Each login (console or remote) has a parent PID that the kernel uses to track all child processes. From connection A you request a find job and from connection B you start a tar process. The kernel internally sees the login PID as the owner of all of those processes. That's why zombies get reassigned to PID 1. Something failed spectacularly and the child didn't die when the parent died. Now there's no way to control the zombie so it get's assigned to PID1 and waits for a reboot.

On Mon, 2015-10-19 at 13:42 -0400, leam hall wrote:
Okay, my brain is being stretched. Could use some expertise. I think the question is on sessions, but it got me thinking about login sessions. If a user ssh's in from Machine X to Machine A, and then opens another terminal window and does the same thing, how does the OS keep the sessions separate?
Leam


_______________________________________________

Ale mailing list

Ale at ale.org<mailto:Ale at ale.org>

http://mail.ale.org/mailman/listinfo/ale

See JOBS, ANNOUNCE and SCHOOLS lists at

http://mail.ale.org/mailman/listinfo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20151019/a788fedb/attachment.html>