Dumping cyclic error_log memory

[Datong Sun]

Hello Robert,

My impression is that the cyclic memory buffer is not shared across
workers. The memory is allocated using ngx_pnalloc and that is not the
shared memory zone. After fork each worker would have their own buffer
instead.

Which probably explains why this is only suitable for debugging, as you
have to know the worker you are trying to debug in order to access the logs
this way.

Thanks,
Datong

On Fri, Jan 3, 2020 at 8:00 PM Robert Paprocki <
rpaprocki at fearnothingproductions.net> wrote:

> Hello,
>
> http://nginx.org/en/docs/debugging_log.html and associated literature
> instruct to dump the contents of a “memory” error_log target via gdb memory
> dump. How is it possible to do this for a given nginx worker process, when
> other worker processes are serving connections simultaneously and
> generating error logs to the shared memory zone (at least, I’m assuming
> it’s shared by all workers, since it’s allocated from the conf pool during
> configuration parsing). Is it possible other workers are memcpy() with a
> dst pointing to the buffer where a simultaneous gdb memory dump is
> executing? Wouldn’t this potentially cause corruption of the read data?
>
> The origin of my question was hacking on a routine that would dump the
> memory buffer to a file from within nginx directly, rather than probing
> into the process with gdb- at first it looks trivial to just write() the
> whole buffer, but since there’s no synchronization mechanism, I anticipate
> this would cause problems in a busy environment.
>
> Sent from my iPhone
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel



-- 
<https://konghq.com/> Datong Sun
Systems Engineer @ Kong <http://konghq.com/>

150 Spear Street, Suite 1600
San Francisco, CA 94105
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20200108/6c83b30d/attachment.htm>