Hello,
> FWIW, related future Squid improvements may include:
> * Detecting such shared memory segments clashes; refusing to start.
> * Disabling shared memory use when caching is completely disabled.
> Quality pull requests welcome.
I looked at the source code and found the detection of the presence of old
shared memory segments ("src/ipc/mem/Segment.cc"):
void
Ipc::Mem::Segment::create(const off_t aSize)
{
assert(aSize > 0);
assert(theFD < 0);
int xerrno = 0;
// Why a brand new segment? A Squid crash may leave a reusable segment,
but
// our placement-new code requires an all-0s segment. We could truncate
and
// resize the old segment, but OS X does not allow using O_TRUNC with
// shm_open() and does not support ftruncate() for old segments.
if (!createFresh(xerrno) && xerrno == EEXIST) {
unlink();
createFresh(xerrno);
}
But, as the comment says, the segments may remain from the previous Squid
crash. Thus, in my opinion, it is impractical to refuse to launch the
program. I think it's enough to put a warning in the code when detecting
old segments.
Something like that:
void
Ipc::Mem::Segment::create(const off_t aSize)
{
assert(aSize > 0);
assert(theFD < 0);
int xerrno = 0;
// Why a brand new segment? A Squid crash may leave a reusable segment,
but
// our placement-new code requires an all-0s segment. We could truncate
and
// resize the old segment, but OS X does not allow using O_TRUNC with
// shm_open() and does not support ftruncate() for old segments.
if (!createFresh(xerrno) && xerrno == EEXIST) {
*debugs(54, DBG_CRITICAL, "WARNING: there is an old shared memory
segment: '" << theName << "'. Perhaps it was left after the previous crash
of the Squid. We will remove it. Or it may be a sign that another instance
of the Squid is running. In this case, you must launch the program with
the -n option and specify the unique name of the service.");*
unlink();
createFresh(xerrno);
}
Kind regards,
Ankor.
сб, 8 мар. 2025 г. в 08:14, Andrey K <ankor2...@gmail.com>:
> Hello Alex,
>
> Thanks for the analysis.
> Squid only allows alphanumeric characters in the service name, so it
> refuses to use the original service name in the -n option (-n
> squid.user.service).
> I added -n squiduser option to the ExecStart string of the second
> instance.
> Now it looks good:
>
> # the first instance
> lsof -p 3746105 | grep shm
> squid 3746105 root mem REG 0,23 525572 1213614834
> /dev/shm/squid-cf__queues.shm
> squid 3746105 root mem REG 0,23 136 1213614835
> /dev/shm/squid-cf__readers.shm
> squid 3746105 root mem REG 0,23 8 1213614833
> /dev/shm/squid-cf__metadata.shm
> squid 3746105 root 7u REG 0,23 8 1213614833
> /dev/shm/squid-cf__metadata.shm
> squid 3746105 root 8u REG 0,23 525572 1213614834
> /dev/shm/squid-cf__queues.shm
> squid 3746105 root 9u REG 0,23 136 1213614835
> /dev/shm/squid-cf__readers.shm
>
> # the second instance
> lsof -p 3685356 | grep shm
> squid.use 3685356 root mem REG 0,23 2093368 1212704041
> /dev/shm/squiduser-tls_session_cache.shm
> squid.use 3685356 root mem REG 0,23 525572 1212704039
> /dev/shm/squiduser-cf__queues.shm
> squid.use 3685356 root mem REG 0,23 136 1212704040
> /dev/shm/squiduser-cf__readers.shm
> squid.use 3685356 root mem REG 0,23 8 1212704038
> /dev/shm/squiduser-cf__metadata.shm
> squid.use 3685356 root 6u REG 0,23 8 1212704038
> /dev/shm/squiduser-cf__metadata.shm
> squid.use 3685356 root 7u REG 0,23 525572 1212704039
> /dev/shm/squiduser-cf__queues.shm
> squid.use 3685356 root 8u REG 0,23 136 1212704040
> /dev/shm/squiduser-cf__readers.shm
> squid.use 3685356 root 9u REG 0,23 2093368 1212704041
> /dev/shm/squiduser-tls_session_cache.shm
>
> Kind regards,
> Ankor.
>
>
>
>
>
> пт, 7 мар. 2025 г. в 17:48, Alex Rousskov <
> rouss...@measurement-factory.com>:
>
>> On 2025-03-07 06:50, Andrey K wrote:
>>
>> > Squid Cache: Version 6.13
>> > Service Name: squid
>>
>> > Squid Cache: Version 6.10
>> > Service Name: squid
>>
>> > # the first instance
>> > 1318 DEL ... 30205 /dev/shm/squid-cf__queues.shm
>> > 1318 DEL ... 30206 /dev/shm/squid-cf__readers.shm
>> > 1318 DEL ... 30204 /dev/shm/squid-cf__metadata.shm
>> > 1318 8u ... 8 30204 /dev/shm/squid-cf__metadata.shm (deleted)
>> > 1318 9u ... 525572 30205 /dev/shm/squid-cf__queues.shm (deleted)
>> > 1318 10u ... 136 30206 /dev/shm/squid-cf__readers.shm (deleted)
>> >
>> > # the second instance
>> > 1514 mem ... 2093368 31497 /dev/shm/squid-tls_session_cache.shm
>> > 1514 mem ... 525572 31495 /dev/shm/squid-cf__queues.shm
>> > 1514 mem ... 136 31496 /dev/shm/squid-cf__readers.shm
>> > 1514 mem ... 8 31494 /dev/shm/squid-cf__metadata.shm
>> > 1514 6u ... 8 31494 /dev/shm/squid-cf__metadata.shm
>> > 1514 7u ... 525572 31495 /dev/shm/squid-cf__queues.shm
>> > 1514 8u ... 136 31496 /dev/shm/squid-cf__readers.shm
>> > 1514 9u ... 2093368 31497 /dev/shm/squid-tls_session_cache.shm
>>
>> As suspected, these two Squid instances use the same shared memory
>> segments (e.g., /dev/shm/squid-cf*). Such shared use violates critical
>> code assumptions and results in undefined behavior.
>>
>>
>> > Maybe I'm not experiencing any difficulties because I have caching
>> turned off on
>> > both instances?
>>
>> Well, you _are_ experiencing at least one difficulty -- the assertion
>> that started this email thread. If you have fully disabled caching, the
>> difficulties you experience should not include cache corruption.
>> However, it looks like at least one of the two instances does cache TLS
>> sessions (in /dev/shm/squid-tls_session_cache.shm). If both instances do
>> that, then all bets are off!
>>
>>
>> FWIW, related future Squid improvements may include:
>>
>> * Detecting such shared memory segments clashes; refusing to start.
>> * Disabling shared memory use when caching is completely disabled.
>>
>> Quality pull requests welcome.
>>
>>
>> Cheers,
>>
>> Alex.
>>
>>
>> > чт, 6 мар. 2025 г. в 17:11, Alex Rousskov:
>> >
>> > On 2025-03-06 08:59, Amos Jeffries wrote:
>> > > On 6/03/25 19:17, Andrey K wrote:
>> > >> Hello,
>> > >>
>> > >> I have a similar configuration: two SMP squids running on the
>> > same OEL
>> > >> host.
>> > >>
>> > >> They were built with different configurations: with different
>> > >> installation path prefixes and different names of binary files:
>> > squid
>> > >> and squid.user and they listen to different ports.
>> > >> They are launched from two different services:squid.service and
>> > >> squid.user.service with the service Type=forking:
>> > >>
>> > >> ExecStart=/usr/sbin/squid -sYC
>> > >> ExecStart=/sbin/squid.user -f /etc/squid.user/squid.conf
>> > >>
>> > >> I have not experienced any troubles with this configuration yet.
>> > >>
>> > >> /> Please be aware that "squid -n ..." is a REQUIREMENT for
>> running/
>> > >> /multiple Squid instances on the same machine regardless of what
>> > features
>> > >> are used./
>> > >>
>> > >> Could you please tell me if I should use the -n option in the
>> > >> ExecStart strings?
>> > >> The arguments of the options should be the service names?
>> > >>
>> > >> ExecStart=/usr/sbin/squid -sYC -n squid.service
>> > >> ExecStart=/sbin/squid.user -f /etc/squid.user/squid.conf -n
>> > >> squid.user.service
>> > >>
>> > > Yes you should. The different ./configure options has helped you
>> > avoid
>> > > major issues, but some may still appear.
>> >
>> > I agree. Moreover, I do not understand how your two SMP Squids could
>> > work correctly without distinct service names because (on OEL) I
>> would
>> > expect them to share the same shared memory segments (which they
>> must
>> > not do to remain distinct instances).
>> >
>> > What is your Squid version? Can you tell how your Squids name their
>> > shared memory segment "files"? For example, on some Linux OSes,
>> those
>> > segments could be in /var/run/shm/ with names like
>> > squid-tr_map_anchors.shm and squid-tr_spaces.shm.
>> >
>> >
>> > Thank you,
>> >
>> > Alex.
>> >
>> > _______________________________________________
>> > squid-users mailing list
>> > squid-users@lists.squid-cache.org
>> > <mailto:squid-users@lists.squid-cache.org>
>> > https://lists.squid-cache.org/listinfo/squid-users
>> > <https://lists.squid-cache.org/listinfo/squid-users>
>> >
>>
>>
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
