Re: monit_http

[Rory Toma]

Just out of curiousity, what version of gcc are you using?

My machine is reasonably fast. For now, I'm adding this:

if (Run.init)
        exit(1);

to the failure of create_server_socket in engine.c:start_httpd

I'm going to add this locally, as it fixes a problem we're seeing, and I
can investigate as to why this happens to me on different systems.

On Mon, 2003-02-17 at 15:23, Jan-Henrik Haukeland wrote:
> Rory Toma <address@hidden> writes:
> 
> > I just tested the fix, and it does not work.
> 
> Well the patch was for avoiding a "zombie" http thread, this is
> another problem.
> 
> > It's easy to reproduce:
> > 
> > skill -9 monit; monit
> > 
> > and you should notice that the monit_http thread did not start:
> 
> Not a problem on my system, RH 7.3 vmlinuz-2.4.18-24.7.x, as I said in
> a previous mail this is OS dependent, and may depend on resources on
> your system or settings. I have a pretty fast system with lots of
> memory which may help:
> 
> hauk:[~]cat /proc/cpuinfo 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 15
> model           : 1
> model name      : Intel(R) Pentium(R) 4 CPU 2.00GHz
> stepping        : 2
> cpu MHz         : 2008.863
> cache size      : 256 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
> bogomips        : 3986.55
> 
> hauk:[~]cat /proc/meminfo 
>         total:    used:    free:  shared: buffers:  cached:
> Mem:  1055907840 609583104 446324736        0 133140480 340324352
> Swap: 271392768        0 271392768
> 
> > 
> > [PST Feb 17 14:37:09] http server: Could not create a server socket at
> > port 1400
> >  -- Address already in use
> > [PST Feb 17 14:37:09] monit HTTP server not available
> > 
> > I believe what we need to do is to send a signal to the other threads
> > and close it all down. If one thread can't start, we should quit.
> 
> Maybe; another option would be to retry binding to the server socket
> port a few times since the OS *will* release the port after a while.
> If this does not succede within a reasonable timespan, we can close
> all threads down. Anyway let's think up a strategy for the 3.3.
> release since I do not feel this is a showstopper for the 3.2 release.
> 
> What do you think?
-- 
Rory Toma               address@hidden
VP of Run Level 5       http://www.trs80.net
Digeo Digital           http://www.digeo.com

signature.asc
Description: This is a digitally signed message part