Dumping cyclic error_log memory

[Robert Paprocki]

Whups, thanks :)

A curious point then, why ngx_atomic_fetch_add is used to advance the buffer position, if an atomic operation isn’t necessary since the buffer isn’t shared. Is it a style choice?

Sent from my iPhone

> On Jan 8, 2020, at 16:50, Datong Sun <datong.sun at konghq.com> wrote:
> 
> 
> 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
> 
> 
> -- 
> 		
> Datong Sun
> 
> Systems Engineer @ Kong 
> 
> 150 Spear Street, Suite 1600
> San Francisco, CA 94105
> 
> 
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20200108/6fb219ba/attachment.htm>