On Tue, Jan 07, 2025 at 02:59:44PM +0100, William Lallemand wrote: > Subject: Re: 3.1.x /dev/shm files? > 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.
I checked again because I had some doubt, but my explanation was not exact. In 3.1 we only keep the shmem between the worker and the master but we close the FD and the shmem is not kept during reload. So if you still have an open FD it could result from an old bug, when upgrading from 3.0 to 3.1 for example. You could check if the HAPROXY_STARTUPLOGS_FD still exist in the master. -- William Lallemand
