On Tue, Jan 07, 2025 at 02:47:48PM +0100, Christian Ruppert wrote: > Subject: Re: 3.1.x /dev/shm files? > On 2025-01-07 14:39, William Lallemand wrote: > > On Tue, Jan 07, 2025 at 12:35:43PM +0100, Christian Ruppert wrote: > > > Subject: 3.1.x /dev/shm files? > > > Hey, > > > > > > nothing major but something I noticed: > > > It looks like in 3.1.x, at least 3.1.1, HAProxy opens and keeps open a > > > /dev/shm file, like here: > > > `haproxy 10493 root DEL REG > > > 0,21 319 /dev/shm/haproxy_startup_logs_10491` > > > This behavior seems new. Is it intended that way or a bug? > > > The FD should closed and/or that file should exist and not being > > > deleted > > > IMO. > > > > > > 1. Start HAProxy > > > 2. lsof | grep haproxy | grep DEL > > > > > > > Hello Christian, > > > > That's the normal behavior, it was introduced with USE_SHM_OPEN in 2.7, > > and is activated by default on linux-glibc, > > linux-musl and freebsd. > > > > It's a mecanism that opens a shm to store the startup-logs between the > > old processes and the new one during reload. > > Allowing to show logs on the "reload" command from the master CLI for > > example. The shm file is opened and then deleted > > so we don't pollute the filesystem, the FD is then kept so we can still > > access to the shared memory. > > > > The mecanism changed a little bit in 3.1, in previous versions the FD > > was closed after the reload and then reopened for > > a new reload, but now we keep the same SHM between reloads. But once > > haproxy is stopped it won't leak anywhere. > > > > Regards, > > Hi William, > > alright. Thanks! :) >
Note that with a recent kernel and lsof you have additionnal details: % sudo lsof | grep shm | grep haproxy haproxy 201470 root mem REG 0,29 45682 [anon_shmem:errors:startup_logs] (stat: No such file or directory) We set an ID on the shared memory zones so we are able to identify them. -- William Lallemand
