lkml.org 
[lkml]   [2000]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ifconfig device down
On Fri, 4 Aug 2000, Alan Curry wrote:

> Jesse Pollard writes the following:
> >the kill(-1,9). It also doesn't kill itself. The signal 15 gives
> >the daemons time to close the connections and exit. If they are not
> >finished by the time the signal 9 occurs, then they are forced out, and the
> >connections left open.
>
> That's not right. SIGKILL forces an exit, which should close all file
> descriptors and FINs should get sent for the ones which are TCP.
>
> do_signal -> do_exit -> __exit_files -> close_files -> fput -> _fput ->
> __fput -> sock_close -> inet_release -> tcp_close -> tcp_send_fin
>
> You can get a RST instead if you had leftover data in the receive queue, but
> either way the connection should not hang around in ESTABLISHED state after
> the process that owned it is gone.

Well I don't hang around long enough to check. This is a code-snippit
of my init in the embedded system:

}
if(pars->status & STAT_REBOOT)
{
DEB(puts("Reboot command received"));
pars->status &= ~STAT_REBOOT;
do {
YIELD;
} while(!!pars->reboot);
DEB(puts("Killing all children"));
(void)kill(-1, SIGTERM);
(void)sleep(1);
(void)kill(-1, SIGKILL);
(void)sleep(1);
DEB(puts("Rebooting the machine"));
(void)sleep(1);
(void)reboot(RB_AUTOBOOT);
}

YIELD is a macro doing usleep(0x10). This is because sched_yield()
just spins, doesn't actually work.

A pars->status is shared memory. A control-task ORs in a STAT_REBOOT flag
into pars->status and sends a signal to init. Init gets the signal
and executes this code. This code waits until the control-task has
reset 'pars->reboot' (the control-task is rebooting another host).
Then the code sends fatal signals to everyone. This, I think, should
have closed all the connections. However, with 2.2.15, they only
get closed after the machine is back up (because of a RST??), not
before the machine shuts down.

This creates a problem if the topography looks like this:

machine1-->machine2-->machine3-->.....machineN

When told to reboot, these machines should "fold-back" from
machine N -> machine1, with the first machine being the last
to reboot. When machine1 comes back up, the other machines
should have already rebooted. The boot sequence takes 10 seconds.

I should be able to reboot the whole chain in slightly more than
10 seconds. Instead, since machine1 doesn't get a disconnect until
machine2 has actually booted, the reboot time ends up being 10*N
seconds where N is the number of hosts. Imagine 30 of these in a
chain (300 seconds = 5 minutes), NotGood(tm).

Now, I notice that if I sleep for about 10 seconds, most connections
do get shut down. However, that makes the reboot sequence take
300 seconds again.


Cheers,
Dick Johnson

Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.031 / U:1.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site