is reparent_to_init a good thing to do?

is reparent_to_init a good thing to do?

[BALBIR SINGH]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

I was looking at the driver under drivers/net/8139too.c, a kernel
thread rtl8139_thread is created, it calls daemonize() and soon
afterwards calls reparent_to_init(). Looking at reparent_to_init(),
it looks like all kernel threads should do this. But, I feel I am missing
something, since not everybody does this.

Is this a good thing to do? or are there special cases when we need this.

Balbir



[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 853 bytes --]

----------------------------------------------------------------------------------------------------------------------
Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and
is intended for use only by the individual or entity to which it is
addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient or it appears that this mail has been forwarded to you without
proper authority, you are notified that any use or dissemination of this
information in any manner is strictly prohibited. In such cases, please
notify us immediately at mailto:mailadmin@wipro.com and delete this mail
from your records.
----------------------------------------------------------------------------------------------------------------------

Re: is reparent_to_init a good thing to do?

[Andrew Morton]

BALBIR SINGH wrote:
> 
> I was looking at the driver under drivers/net/8139too.c, a kernel
> thread rtl8139_thread is created, it calls daemonize() and soon
> afterwards calls reparent_to_init(). Looking at reparent_to_init(),
> it looks like all kernel threads should do this. But, I feel I am missing
> something, since not everybody does this.
> 
> Is this a good thing to do? or are there special cases when we need this.
> 

I think yes, more kernel threads need to use this function.  Most
particularly, threads which are parented by a userspace application
and which can terminate.  For example, the nfsd threads.

Right now, it's probably the case that nfsd threads will turn
into zombies when they terminate, *if* their parent is still
running.   But of course, most kernel threads are parented
by very short-lived userspace applications, so nobody has
ever noticed.

Re: is reparent_to_init a good thing to do?

[Rob Landley]

On Tuesday 09 October 2001 12:13, Andrew Morton wrote:

> I think yes, more kernel threads need to use this function.  Most
> particularly, threads which are parented by a userspace application
> and which can terminate.  For example, the nfsd threads.
>
> Right now, it's probably the case that nfsd threads will turn
> into zombies when they terminate, *if* their parent is still
> running.   But of course, most kernel threads are parented
> by very short-lived userspace applications, so nobody has
> ever noticed.

Or long lived kernel threads from short lived login sessions.

You have a headless gateway box for your local subnet, administered via ssh 
from a machine on the local subnet.  So you SSH into the box through eth1, 
ifconfig eth0 down back up again.  If eth0 is an rtl8039too, this fires off a 
kernel thread (which, before reparent_to_init, was parented to your ssh login 
session).

Now exit the login session.  SSH does not exit until all the child processes 
exit, so it just hangs there until you kill it from another console window...

Rob

Re: is reparent_to_init a good thing to do?

[BALBIR SINGH]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

Rob Landley wrote:

>Or long lived kernel threads from short lived login sessions.
>
>You have a headless gateway box for your local subnet, administered via ssh 
>from a machine on the local subnet.  So you SSH into the box through eth1, 
>ifconfig eth0 down back up again.  If eth0 is an rtl8039too, this fires off a 
>kernel thread (which, before reparent_to_init, was parented to your ssh login 
>session).
>
>Now exit the login session.  SSH does not exit until all the child processes 
>exit, so it just hangs there until you kill it from another console window...
>
>Rob
>
The question one can ask is what should a thread do then?
Should reparent_to_init() send a SIGCHLD to the process/task
that was parent before init became the parent? this should be easy
to do, but will this fix the problem? I think so.

I can patch up something soon, if somebody is willing to test it.

comments,
Balbir




[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 853 bytes --]

----------------------------------------------------------------------------------------------------------------------
Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and
is intended for use only by the individual or entity to which it is
addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient or it appears that this mail has been forwarded to you without
proper authority, you are notified that any use or dissemination of this
information in any manner is strictly prohibited. In such cases, please
notify us immediately at mailto:mailadmin@wipro.com and delete this mail
from your records.
----------------------------------------------------------------------------------------------------------------------

Re: is reparent_to_init a good thing to do?

[BALBIR SINGH]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

Balbir Singh wrote:

> Rob Landley wrote:
>
>> Or long lived kernel threads from short lived login sessions.
>>
>> You have a headless gateway box for your local subnet, administered 
>> via ssh from a machine on the local subnet.  So you SSH into the box 
>> through eth1, ifconfig eth0 down back up again.  If eth0 is an 
>> rtl8039too, this fires off a kernel thread (which, before 
>> reparent_to_init, was parented to your ssh login session).
>>
>> Now exit the login session.  SSH does not exit until all the child 
>> processes exit, so it just hangs there until you kill it from another 
>> console window...
>>
>> Rob
>>
> The question one can ask is what should a thread do then?
> Should reparent_to_init() send a SIGCHLD to the process/task
> that was parent before init became the parent? this should be easy
> to do, but will this fix the problem? I think so.
>
> I can patch up something soon, if somebody is willing to test it.


Ooh! sorry this is a wrong approach to send SIGCHLD to the previous parent.
AFAIK, all shells send their children SIGHUP when the shell exits, but SSH
may have some special security consideration in waiting for all children to
exit, does anyone know?

Balbir

>
> comments,
> Balbir
>
>
>




[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 853 bytes --]

----------------------------------------------------------------------------------------------------------------------
Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and
is intended for use only by the individual or entity to which it is
addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient or it appears that this mail has been forwarded to you without
proper authority, you are notified that any use or dissemination of this
information in any manner is strictly prohibited. In such cases, please
notify us immediately at mailto:mailadmin@wipro.com and delete this mail
from your records.
----------------------------------------------------------------------------------------------------------------------

Re: is reparent_to_init a good thing to do?

[Rob Landley]

On Wednesday 10 October 2001 09:02, BALBIR SINGH wrote:
> Balbir Singh wrote:
> > Rob Landley wrote:
> >> Or long lived kernel threads from short lived login sessions.
...
> Ooh! sorry this is a wrong approach to send SIGCHLD to the previous parent.
> AFAIK, all shells send their children SIGHUP when the shell exits, but SSH
> may have some special security consideration in waiting for all children to
> exit, does anyone know?
>
> Balbir

The problem I mentioned above was the reason "reparent_to_init" was created 
in the first place.  Here it is in the archive:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0105.0/0045.html

I.E. already fixed...

Google could probably find Jimmy Hoffa given half a chance...  (If we could 
just figure out how to connect it up to maps.yahoo.com...)

Rob

Re: is reparent_to_init a good thing to do?

[Pete Zaitcev]

> Right now, it's probably the case that nfsd threads will turn
> into zombies when they terminate, *if* their parent is still
> running.   But of course, most kernel threads are parented
> by very short-lived userspace applications, so nobody has
> ever noticed.

Oh, this is how khubd zombies get about. Now I see...

-- Pete

Re: is reparent_to_init a good thing to do?

[Jesse Pollard]

"BALBIR SINGH" <balbir.singh@wipro.com>:
> Balbir Singh wrote:
> 
> > Rob Landley wrote:
> >
> >> Or long lived kernel threads from short lived login sessions.
> >>
> >> You have a headless gateway box for your local subnet, administered 
> >> via ssh from a machine on the local subnet.  So you SSH into the box 
> >> through eth1, ifconfig eth0 down back up again.  If eth0 is an 
> >> rtl8039too, this fires off a kernel thread (which, before 
> >> reparent_to_init, was parented to your ssh login session).
> >>
> >> Now exit the login session.  SSH does not exit until all the child 
> >> processes exit, so it just hangs there until you kill it from another 
> >> console window...
> >>
> >> Rob
> >>
> > The question one can ask is what should a thread do then?
> > Should reparent_to_init() send a SIGCHLD to the process/task
> > that was parent before init became the parent? this should be easy
> > to do, but will this fix the problem? I think so.
> >
> > I can patch up something soon, if somebody is willing to test it.
> 
> 
> Ooh! sorry this is a wrong approach to send SIGCHLD to the previous parent.
> AFAIK, all shells send their children SIGHUP when the shell exits, but SSH
> may have some special security consideration in waiting for all children to
> exit, does anyone know?

Not exactly - sshd will not terminate a connection until all forwarded socket
connections are terminated. If processes are running in the background, then
they will remain after sshd terminates. Foreground processes will terminate as
specified by the shell.

If the sshd TCP socket remains open after the network interface is shutdown,
then you are into the TCP timeout.. Not a ssh logout.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.