On 2025-01-07 15:51, William Lallemand wrote:
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.
It was restarted, not reloaded:
zsh 10053 # lsof | grep haproxy | grep DEL
haproxy 10493 root DEL REG
0,21 319 /dev/shm/haproxy_startup_logs_10491
haproxy 10494 haproxy DEL REG
0,1 66990 /dev/zero
haproxy 10494 10495 haproxy haproxy DEL REG
0,1 66990 /dev/zero
haproxy 10494 10496 haproxy haproxy DEL REG
0,1 66990 /dev/zero
haproxy 10494 10497 haproxy haproxy DEL REG
0,1 66990 /dev/zero
haproxy 10494 10498 haproxy haproxy DEL REG
0,1 66990 /dev/zero
haproxy 10494 10499 haproxy haproxy DEL REG
0,1 66990 /dev/zero
haproxy 10494 10500 haproxy haproxy DEL REG
0,1 66990 /dev/zero
haproxy 10494 10501 haproxy haproxy DEL REG
0,1 66990 /dev/zero
zsh 10054 # ps aux|grep hapro
root 10493 0.0 0.0 92416 8384 ? Ss 12:22 0:00
/usr/sbin/haproxy -D -W -p /run/haproxy.pid -f /etc/haproxy/haproxy.cfg
-S /run/haproxy-master.sock
haproxy 10494 0.0 0.0 547340 28852 ? Sl 12:22 0:08
/usr/sbin/haproxy -D -W -p /run/haproxy.pid -f /etc/haproxy/haproxy.cfg
-S /run/haproxy-master.sock
root 15127 0.0 0.0 6600 2176 pts/6 S+ 15:55 0:00 grep
--color=auto hapro
3.1.1 stable. I'm not sure if 3.1.0 was affected as well but before
3.1.x I haven't seen that for sure.
--
Regards,
Christian Ruppert
