Re: [BProc] BProc & /dev/tty - anything to watch out?

[Erik A. H. <er...@he...>]

On Wed, May 22, 2002 at 05:56:32PM +0200, ha...@no... wrote:
> Hi, me again :-)
> 
> Seemes to be possible to let this always hold for masq-ed process:
> 
>   current->pgrp == current->bproc.masq->pgrp
>   current->session == current->bproc.masq->session
> 
> (these values therefore mostly differ from current->pid)
> 
> Looks strange at first, some basic BProc ideas seemes to be shaken,
> but it may be workable approach. Comments welcome, of course.
> 
> There are hunderds of places where pgrp/session is used in some
> way. No chance to even look at all of them.
> 
> However there are just few places where kernel compares pid to
> pgrp/session. Should be easy to fix any broken details.
> 
> I modified masq_setsid() and masq_setpgid() to also save new values to
> normal pgrp and session and things look promissing.  Now I can login
> to node via ssh without any complaints, run some commands and try to
> logout - where it hangs now (in select(), do not have details yet).
> 
> Now it also complains (on master) once per every command run from
> login bash:
> 
>    kernel: bproc: ghost(2124): failed to wait on 2132.options=2  err=-10
> 
> But I guess I would work these things out. Most of all, I would like
> to here your comments on the idea of using master's pgrp and session
> also in normal non-masq-ed process information on slave.

You're right about using the non-masq-ed being not in line with
BProc's design.  I think it should lead to some weirdness on the slave
node.  Mostly because process groups, etc are allocated with basically
the same rules as other process IDs and this will be poking in
basically random values in the slave's local process tree.

I'm surprised you're getting that error on the master though.  That
suggests that something has gotten out of sync between the slave and
the master.  Are you accumulating zombies on the front end?  Do the
process IDs (2124 & 2132) make any sense?

Having looked through the TTY code a little bit, I think the "right"
answer will be to modify it in line with other process group related
code in the kernel.  A "leader" flag will probably have to be added to
the bproc_masq_bproc_t structure.  It's not trivial though since it
likes to store PG and session IDs in its own data structures.  It
might also require allocating a PID on the slave to represent process
groups whose ID isn't already pressent on the slave.

It's gonna be messy in any case...  I need to look at this more
closely.

- Erik