Re: tux dies when using a module

ah! excellent then. i will give that a try.

i am new to this list (and to tux), however, and i don't know the
best source for tux kernel patches.

i'm looking at http://people.redhat.com/mingo/TUX-patches/ but the
latest patch is dated 02-apr-2002. which patch should i use?

On 10/02/02, Alex Kramarov <[email protected]> wrote: 

> I can only remind of the 99% cpu bug, and that it was fixed in the latest
> tux patch. redhat's kernel contains much earlier version. maybe your module
> triggers the bug much more often then it was manifesting itself in these
> versions normally. the simptoms you describe similar to that bug.
>  
> -------Original Message-------
>  
> From: [email protected]
> Date: éåí øáéòé 02 àå÷èåáø 2002 10:31:55
> To: [email protected]
> Subject: tux dies when using a module
>  
> hi there.
>  
> i've been using tux successfully on a production web server for about
> two months. recently i wrote a simple tux module, similar to demo2.c,
> that serves files based on whether or not the browser has a particular
> cookie set. the purpose is to protect proprietary files, without
> rewriting all of apache's htaccess into tux.
>  
> anyway, the module worked fine on my test server, but as soon as i ran
> it on our busy production server, one of the worker threads sucked up
> 99% of the CPU, and tux became useless. it was then impossible to kill
> any of the tux processes. i had to reboot the machine for it to return
> to sanity.
>  
> when the machine came back up, i found this in /var/log/messages:
>  
> Oct 2 00:58:07 sg1 kernel: Process tux (pid: 2068, stackpage=df649000)
> Oct 2 00:58:07 sg1 kernel: [<f89aa006>] flush_request [tux] 0x566 
> Oct 2 00:58:07 sg1 kernel: [<f89c7fc8>] threadinfo [tux] 0x268 
> Oct 2 00:58:07 sg1 kernel: [<f89a9227>] redirect_request [tux] 0x67 
> Oct 2 00:58:07 sg1 kernel: [<f89c7fc8>] threadinfo [tux] 0x268 
> Oct 2 00:58:07 sg1 kernel: [<f89a71a8>] tux_schedule_atom [tux] 0x18 
> Oct 2 00:58:07 sg1 kernel: [<f89a807b>] process_requests [tux] 0x8b 
> Oct 2 00:58:07 sg1 kernel: [<f89c8114>] threadinfo [tux] 0x3b4 
> Oct 2 00:58:07 sg1 kernel: [<f89c7fc8>] threadinfo [tux] 0x268 
> Oct 2 00:58:07 sg1 kernel: [<f89c7fc8>] threadinfo [tux] 0x268 
> Oct 2 00:58:07 sg1 kernel: [<f89b2d05>] event_loop [tux] 0x75 
> Oct 2 00:58:07 sg1 kernel: [<f89c7fc8>] threadinfo [tux] 0x268 
> Oct 2 00:58:07 sg1 kernel: [<f89b4bcb>] __sys_tux [tux] 0x4eb 
> Oct 2 00:58:07 sg1 kernel: [<f89c7fc8>] threadinfo [tux] 0x268 
> Oct 2 00:58:07 sg1 kernel: [<c01d6e22>] sys_tux [kernel] 0x22 
>  
> any idea where i should start? i can't reproduce the problem on my
> test server, which is an exact clone of the production server. i'm
> running redhat 7.3 and the latest rpm of tux.
>  
> any help that anyone can provide would be greatly appreciated.
>  
> -- 
>  
> steve simitzis : /sim' - i - jees/
> pala : saturn5 productions
> www.steve.org : 415.282.9979
> hath the daemon spawn no fire?
>  
>  
>  
> _______________________________________________
> tux-list mailing list
> [email protected]
> https://listman.redhat.com/mailman/listinfo/tux-list
>  
> . 
> 
> 
> 
> _______________________________________________
> tux-list mailing list
> [email protected]
> https://listman.redhat.com/mailman/listinfo/tux-list

-- 

steve simitzis : /sim' - i - jees/
          pala : saturn5 productions
 www.steve.org : 415.282.9979
  hath the daemon spawn no fire?