<div dir="ltr">Hello Alex,<div><br></div><div>Thank you for sharing your thoughts.</div><div>The A-example looks easier to implement and more reliable.</div><div><br></div><div>Kind regards,</div><div> Ankor.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">вт, 11 мар. 2025 г. в 17:12, Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2025-03-10 23:56, Andrey K wrote:<br>
<br>
> > Alex: FWIW, related future Squid improvements may include:<br>
> > * Detecting such shared memory segments clashes; refusing to start.<br>
> > * Disabling shared memory use when caching is completely disabled.<br>
<br>
> But ... segments may remain from the previous <br>
> Squid crash. Thus, in my opinion, it is impractical to refuse to launch <br>
> the program.<br>
<br>
"Squid should overwrite segments left by a crashed Squid" does not imply <br>
that "detecting segment clashes among independent Squid instances is <br>
impractical".<br>
<br>
The following rough examples are _not_ implementation blueprints, but <br>
they illustrate the lack of the above implication:<br>
<br>
A. If Squid were to incorporate PID filename[^1] into segment names, <br>
then segments from different Squid instances will not clash.<br>
<br>
B. If Squid were to write its PID filename[^1] into a shared memory <br>
segment, then Squid would be able to detect that another running <br>
instance is using the same shared memory segment (while still <br>
overwriting segments left by an earlier crash).<br>
<br>
<br>
[^1]: Full Squid PID filename are already guaranteed to be unique across <br>
Squid instances that may overwrite each other segments because Squid <br>
refuses to start if another Squid instance is using its PID file. The <br>
only red flag I can think of here is esoteric chrooted instances, but I <br>
would not be surprised if those instances cannot share segments.<br>
<br>
<br>
> I think it's enough to put a warning in the code when detecting old<br>
> segments.<br>
<br>
I disagree that a level-0 warning during regular/uneventful startups is <br>
a good idea, especially if there will be one warning for every segment. <br>
We should try to address the actual problem (i.e. refuse to start a <br>
segment-clashing concurrent instance) rather than allowing clashes but <br>
adding a yet another warning about a usually benign event.<br>
<br>
Alex.<br>
<br>
<br>
> Something like that:<br>
> void<br>
> Ipc::Mem::Segment::create(const off_t aSize)<br>
> {<br>
> assert(aSize > 0);<br>
> assert(theFD < 0);<br>
> <br>
> int xerrno = 0;<br>
> <br>
> // Why a brand new segment? A Squid crash may leave a reusable <br>
> segment, but<br>
> // our placement-new code requires an all-0s segment. We could <br>
> truncate and<br>
> // resize the old segment, but OS X does not allow using O_TRUNC with<br>
> // shm_open() and does not support ftruncate() for old segments.<br>
> if (!createFresh(xerrno) && xerrno == EEXIST) {<br>
> *debugs(54, DBG_CRITICAL, "WARNING: there is an old shared memory <br>
> segment: '" << theName << "'. Perhaps it was left after the previous <br>
> crash of the Squid. We will remove it. Or it may be a sign that another <br>
> instance of the Squid is running. In this case, you must launch the <br>
> program with the -n option and specify the unique name of the service.");*<br>
> unlink();<br>
> createFresh(xerrno);<br>
> }<br>
> Kind regards,<br>
> Ankor.<br>
> <br>
> <br>
> сб, 8 мар. 2025 г. в 08:14, Andrey K <<a href="mailto:ankor2023@gmail.com" target="_blank">ankor2023@gmail.com</a> <br>
> <mailto:<a href="mailto:ankor2023@gmail.com" target="_blank">ankor2023@gmail.com</a>>>:<br>
> <br>
> Hello Alex,<br>
> <br>
> Thanks for the analysis.<br>
> Squidonlyallowsalphanumericcharactersinthe servicename,<br>
> soitrefusesto usethe originalservice namein the -n option (-n<br>
> squid.user.service).<br>
> I added-n squiduser option to the ExecStart string of the second<br>
> instance.<br>
> Now it looks good:<br>
> <br>
> # the first instance<br>
> lsof -p 3746105 | grep shm<br>
> squid 3746105 root mem REG 0,23 525572<br>
> 1213614834 /dev/shm/squid-cf__queues.shm<br>
> squid 3746105 root mem REG 0,23 136<br>
> 1213614835 /dev/shm/squid-cf__readers.shm<br>
> squid 3746105 root mem REG 0,23 8<br>
> 1213614833 /dev/shm/squid-cf__metadata.shm<br>
> squid 3746105 root 7u REG 0,23 8<br>
> 1213614833 /dev/shm/squid-cf__metadata.shm<br>
> squid 3746105 root 8u REG 0,23 525572<br>
> 1213614834 /dev/shm/squid-cf__queues.shm<br>
> squid 3746105 root 9u REG 0,23 136<br>
> 1213614835 /dev/shm/squid-cf__readers.shm<br>
> <br>
> # the second instance<br>
> lsof -p 3685356 | grep shm<br>
> squid.use 3685356 root mem REG 0,23 2093368<br>
> 1212704041 /dev/shm/squiduser-tls_session_cache.shm<br>
> squid.use 3685356 root mem REG 0,23 525572<br>
> 1212704039 /dev/shm/squiduser-cf__queues.shm<br>
> squid.use 3685356 root mem REG 0,23 136<br>
> 1212704040 /dev/shm/squiduser-cf__readers.shm<br>
> squid.use 3685356 root mem REG 0,23 8<br>
> 1212704038 /dev/shm/squiduser-cf__metadata.shm<br>
> squid.use 3685356 root 6u REG 0,23 8<br>
> 1212704038 /dev/shm/squiduser-cf__metadata.shm<br>
> squid.use 3685356 root 7u REG 0,23 525572<br>
> 1212704039 /dev/shm/squiduser-cf__queues.shm<br>
> squid.use 3685356 root 8u REG 0,23 136<br>
> 1212704040 /dev/shm/squiduser-cf__readers.shm<br>
> squid.use 3685356 root 9u REG 0,23 2093368<br>
> 1212704041 /dev/shm/squiduser-tls_session_cache.shm<br>
> <br>
> Kind regards,<br>
> Ankor.<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> пт, 7 мар. 2025 г. в 17:48, Alex Rousskov<br>
> <<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a><br>
> <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>>>:<br>
> <br>
> On 2025-03-07 06:50, Andrey K wrote:<br>
> <br>
> > Squid Cache: Version 6.13<br>
> > Service Name: squid<br>
> <br>
> > Squid Cache: Version 6.10<br>
> > Service Name: squid<br>
> <br>
> > # the first instance<br>
> > 1318 DEL ... 30205 /dev/shm/squid-cf__queues.shm<br>
> > 1318 DEL ... 30206 /dev/shm/squid-cf__readers.shm<br>
> > 1318 DEL ... 30204 /dev/shm/squid-cf__metadata.shm<br>
> > 1318 8u ... 8 30204 /dev/shm/squid-cf__metadata.shm<br>
> (deleted)<br>
> > 1318 9u ... 525572 30205 /dev/shm/squid-cf__queues.shm<br>
> (deleted)<br>
> > 1318 10u ... 136 30206 /dev/shm/squid-cf__readers.shm<br>
> (deleted)<br>
> ><br>
> > # the second instance<br>
> > 1514 mem ... 2093368 31497<br>
> /dev/shm/squid-tls_session_cache.shm<br>
> > 1514 mem ... 525572 31495 /dev/shm/squid-cf__queues.shm<br>
> > 1514 mem ... 136 31496 /dev/shm/squid-cf__readers.shm<br>
> > 1514 mem ... 8 31494 /dev/shm/squid-cf__metadata.shm<br>
> > 1514 6u ... 8 31494 /dev/shm/squid-cf__metadata.shm<br>
> > 1514 7u ... 525572 31495 /dev/shm/squid-cf__queues.shm<br>
> > 1514 8u ... 136 31496 /dev/shm/squid-cf__readers.shm<br>
> > 1514 9u ... 2093368 31497<br>
> /dev/shm/squid-tls_session_cache.shm<br>
> <br>
> As suspected, these two Squid instances use the same shared memory<br>
> segments (e.g., /dev/shm/squid-cf*). Such shared use violates<br>
> critical<br>
> code assumptions and results in undefined behavior.<br>
> <br>
> <br>
> > Maybe I'm not experiencing any difficulties because I have<br>
> caching turned off on<br>
> > both instances?<br>
> <br>
> Well, you _are_ experiencing at least one difficulty -- the<br>
> assertion<br>
> that started this email thread. If you have fully disabled<br>
> caching, the<br>
> difficulties you experience should not include cache corruption.<br>
> However, it looks like at least one of the two instances does<br>
> cache TLS<br>
> sessions (in /dev/shm/squid-tls_session_cache.shm). If both<br>
> instances do<br>
> that, then all bets are off!<br>
> <br>
> <br>
> FWIW, related future Squid improvements may include:<br>
> <br>
> * Detecting such shared memory segments clashes; refusing to start.<br>
> * Disabling shared memory use when caching is completely disabled.<br>
> <br>
> Quality pull requests welcome.<br>
> <br>
> <br>
> Cheers,<br>
> <br>
> Alex.<br>
> <br>
> <br>
> > чт, 6 мар. 2025 г. в 17:11, Alex Rousskov:<br>
> ><br>
> > On 2025-03-06 08:59, Amos Jeffries wrote:<br>
> > > On 6/03/25 19:17, Andrey K wrote:<br>
> > >> Hello,<br>
> > >><br>
> > >> I have a similar configuration: two SMP squids<br>
> running on the<br>
> > same OEL<br>
> > >> host.<br>
> > >><br>
> > >> They were built with different configurations: with<br>
> different<br>
> > >> installation path prefixes and different names of<br>
> binary files:<br>
> > squid<br>
> > >> and squid.user and they listen to different ports.<br>
> > >> They are launched from two different<br>
> services:squid.service and<br>
> > >> squid.user.service with the service Type=forking:<br>
> > >><br>
> > >> ExecStart=/usr/sbin/squid -sYC<br>
> > >> ExecStart=/sbin/squid.user -f<br>
> /etc/squid.user/squid.conf<br>
> > >><br>
> > >> I have not experienced any troubles with this<br>
> configuration yet.<br>
> > >><br>
> > >> /> Please be aware that "squid -n ..." is a<br>
> REQUIREMENT for running/<br>
> > >> /multiple Squid instances on the same machine<br>
> regardless of what<br>
> > features<br>
> > >> are used./<br>
> > >><br>
> > >> Could you please tell me if I should use the -n<br>
> option in the<br>
> > >> ExecStart strings?<br>
> > >> The arguments of the options should be the service names?<br>
> > >><br>
> > >> ExecStart=/usr/sbin/squid -sYC -n squid.service<br>
> > >> ExecStart=/sbin/squid.user -f<br>
> /etc/squid.user/squid.conf -n<br>
> > >> squid.user.service<br>
> > >><br>
> > > Yes you should. The different ./configure options has<br>
> helped you<br>
> > avoid<br>
> > > major issues, but some may still appear.<br>
> ><br>
> > I agree. Moreover, I do not understand how your two SMP<br>
> Squids could<br>
> > work correctly without distinct service names because (on<br>
> OEL) I would<br>
> > expect them to share the same shared memory segments<br>
> (which they must<br>
> > not do to remain distinct instances).<br>
> ><br>
> > What is your Squid version? Can you tell how your Squids<br>
> name their<br>
> > shared memory segment "files"? For example, on some Linux<br>
> OSes, those<br>
> > segments could be in /var/run/shm/ with names like<br>
> > squid-tr_map_anchors.shm and squid-tr_spaces.shm.<br>
> ><br>
> ><br>
> > Thank you,<br>
> ><br>
> > Alex.<br>
> ><br>
> > _______________________________________________<br>
> > squid-users mailing list<br>
> > <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
> <mailto:<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a>><br>
> > <mailto:<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
> <mailto:<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a>>><br>
> > <a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a><br>
> <<a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a>><br>
> > <<a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a><br>
> <<a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a>>><br>
> ><br>
> <br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div>