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
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.
> 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
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
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
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
>
>
>
"BALBIR SINGH" <[email protected]>:
> 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: [email protected]
Any opinions expressed are solely my own.
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