Re: monit_http

[Jan-Henrik Haukeland]

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?

-- 
Jan-Henrik Haukeland