Sockets are registering semaphores in external object table, to be
able signaled by socket plugin.
When image starting after booting VM, an external object table is
cleared and replaced by empty fresh array.
So, if there is any process(es) left in saved image which waiting on
such semaphores to be signaled via external event (as sockets), they
will never awake, because there's no one who can signal them.
To get around problem, at startup phase, we should do something like that:
   Socket allInstancesDo: [:s | s signalAndClearSemaphores ].
So, any process which has waiting for given semaphores will have a
chance to get  past the lock and die.

As for gracious shutdown/startup, to prevent interrupting process
which saving image by some process who can handle network requests, i
think best way is to suspend all active processes except one, which
saving image. And then resume them after save done.
But lately, when i tried to do it myself, i found that it's not
possible, due to bug in #resume:  (see other discussion about
suspend/resume).
So, we need to wait until it will be fixed, or find a way around.

On 24/12/2007, Andreas Raab <andreas.raab at gmx.de> wrote:
> Lukas Renggli wrote:
> > The doIt you sent comes out empty, I've never seen a case where it
> > actually returned a process. For the stack dumps I've got only the
> > attached screenshot from the process browser that I took December 5.,
> > roughly a month after loading your patches.
>
> Unfortunately, the screenshot doesn't show much interesting - the best
> thing to do is to cover *all* processes when the system is locked up for
> forensic analysis. What we have done in our server VMs is to hook up the
> USR1 signal to the VM's printAllStacks() function so that we can simply
> get a stack dump via kill -USR1 <pid_of_squeak>. I don't know if this is
> in the standard Unix VMs (I have no idea how portable the code is) but
> it's a must have feature for running a Linux server with Squeak.
>
> > Current versions of the Kom server adapter for Seaside stop listening
> > while saving the image, but I have to check if this is also the case
> > with the version of Seaside used in squeaksource.com.
>
> That's a likely cause for problems. Also, you probably need to make sure
> all requests are finished before saving the image - otherwise some of
> them may rely on network activity to wake up.
>
> Cheers,
>    - Andreas
>
>
>


-- 
Best regards,
Igor Stasenko AKA sig.