Henning,

    No earlier errors, kamailio starts up like normal from a syslog point of view, "RTP Enabled" followed by:

verbose 3
Jun 16 16:30:14 sipdev /sbin/kamailio[6364]: CRITICAL:core:init_io_wait: could not alloc epoll array
Jun 16 16:30:14 sipdev /sbin/kamailio[6364]: CRITICAL:core:tcp_receive_loop: exiting...
Jun 16 16:30:14 sipdev /sbin/kamailio[6338]: INFO:core:handle_sigs: child process 6364 exited normally, status=255
Jun 16 16:30:14 sipdev /sbin/kamailio[6338]: INFO:core:handle_sigs: terminating due to SIGCHLD

verbose 5: pretty much shows the same:
Jun 16 16:33:57 sipdev /sbin/kamailio[6537]: CRITICAL:core:init_io_wait: could not alloc epoll array
Jun 16 16:33:57 sipdev /sbin/kamailio[6537]: CRITICAL:core:tcp_receive_loop: exiting...
Jun 16 16:33:57 sipdev /sbin/kamailio[6541]: CRITICAL:core:receive_fd: EOF on 40
Jun 16 16:33:57 sipdev /sbin/kamailio[6538]: CRITICAL:core:init_io_wait: could not alloc epoll array
Jun 16 16:33:57 sipdev /sbin/kamailio[6538]: CRITICAL:core:tcp_receive_loop: exiting...

No other errors that I can see.

On Tue, Jun 16, 2009 at 8:03 AM, Henning Westerholt <henning.westerholt@1und1.de> wrote:
On Dienstag, 16. Juni 2009, Brandon Armstead wrote:
> I'm adding a single avp test i.e. $avp(s:some-avp-name) = 'foo!'; to a
> development configuration running Kamailio revision: 5487 (1.4.3). When I
> start kamailio I'm getting the following error:


Hi Brandon,


> CRITICAL:core:init_io_wait: could not alloc epoll array


I'd guess this is related to the EPOLL support that is used to efficiently get notified when something on the file descriptor arrives, so basically its necessary for TCP support.


> As soon as I delete this AVP addition and start her back up, she starts.
>
>
> Code Snippet (io_wait.c)
>
> 606 #ifdef HAVE_EPOLL
> [..]

> 620 #endif
>
> I do not know enough of Kamailio CORE but it looks like something to do
> with memory allocation / file descriptors? I've increased available memory
> to kamailio as well as open file limits / file descriptors etc -- to no
> avail, any help is much appreciated thanks guys!


This is really strange, i really could not imagine how an AVP operation like this could be related to the TCP core infrastructure. Do you notice some other (earlier) errors in the logs? Perhaps its just something that its generated because its stop from an earlier error?


Henning