On Thu, Jan 02, 2003 at 12:36:52AM -0600, Bob Maccione wrote:
> Thanks Al, but the problem seems to be that I can do a 'delete
> $heap->{Client}' if I don't do any work but as soon as I do some work the
> delete doesn't seem to work anymore.
delete $heap->{Client} may technically work, but it's not recommended.
Al's suggested $kernel->yield("shutdown") is the documented way to
shut down a client connection.
> I'm building a replacement for init
> (http://www.netsys.com/cgi-bin/man2html?/usr/share/man/cat1m/init.1m) that
> supports a cron and telnet interface for controlling a box/application. The
> good news is that it's pretty close. I'll soon have a PoCo::Component::Cron
> and it's not too bad. It also has a web server built in for doing status
> and http control.
This sounds great. I wish I could see the entire init replacement.
> The problem is when I kill a Wheel::Run and then try to delete the client it
> no longer closes the client connection (although the Init process stops
> taking IO from that session).
>
> I'm thinking that there is an unanswered event or something that is hosing
> up telnet server but haven't found it yet.
>
> Any Wheel::Run folks experience this before.
It may also be that some child process has a copy of the opened
socket. Is it possible that the socket's close-on-exec flag is off?
You can check/set it with fcntl(2).
I've never seen it happen, but you're probably exercising Wheel::Run
more than I ever have. If possible, can you distill the problem into
a test case?
> Also (in solaris) I'm finding if I start a process that's a shell and kill
> the shell, the process doesn't die.
>
> example:
>
> Init runs start.sh
>
> start.sh is:
> #!/bin/ksh
> runsomething
> -----
>
> so we have:
>
> Init
> start.sh
> runsomething
>
> If I kill start.sh (via a kill "HUP" pid) I get:
>
> Init
>
> runsomething <-- now owned by init (pid 1).
>
> If I kill the Init server then runsomething goes away.. very strange.
Killing the Init server causes all the child processes have their
STDIN and STDOUT suddenly go away. I don't know what happens next,
but it's probably fatal all down the tree of processes.
Is it possible that your Solaris shell isn't propagating SIGHUP to
runsomething?
A test case would be helpful here, too.
-- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
