On 2023-09-14 06:40, Loučanský Lukáš wrote:

But - could someone (or you) clarify the next one for me? I've read some questions about the "new" cachemgr.cgi and the MGR_INDEX template.

Sorry, I cannot help with cachemgr.cgi without heroic efforts. IMHO, Squid Project should remove cachemgr.cgi feature instead of supporting it. I hope that somebody else will help you with it.


Besides that I have found out that every time I shutdown squid with start-stop-daemon it coredumps.

user 13 dumped core.#012#012Stack trace of thread 23990:
#012#2  0x000055c7eca80694 xassert (squid)
#012#3  0x000055c7ecb23c7c _ZN5Store4RootEv (squid)
#012#4  0x000055c7ec8805af _ZN10StoreEntry16destroyMemObjectEv (squid)
#012#5  0x000055c7ec8811f6 _Z17destroyStoreEntryPv (squid)
#012#6  0x000055c7ecb2d3eb hashFreeItems (squid)
#012#7  0x000055c7ecb1fe4a _ZN5Store10ControllerD1Ev (squid)
#012#8  0x000055c7ecb1fec9 _ZN5Store10ControllerD0Ev (squid)
#012#9  0x00007f35c21adebc __run_exit_handlers (libc.so.6)
#012#10 0x00007f35c21adfea __GI_exit (libc.so.6)
#012#11 0x000055c7ec847ce3 SquidShutdown (squid)

Yes, "TheRoot" assertions after shutdown (during "automatic" at-exit cleanup) is a known bug. Recent shutdown improvements make this particular assertion more likely, unfortunately. More difficult work is needed to fully solve the underlying problem. We will solve it.

Meanwhile, please try the attached patch with an untested workaround. Does it help in your environment?


Thank you,

Alex.


-----Původní zpráva-----
Od: squid-users za uživatele Alex Rousskov
Odesláno: st 13.9.2023 20:53
Komu: squid-users@lists.squid-cache.org
Předmět: Re: [squid-users] Squid BUG: assurance failed: tok.skip(WellKnownUrlPathPrefix())

On 2023-09-12 15:50, Loučanský Lukáš wrote:

 > 2023/09/12 19:12:03 kid4| ERROR: Squid BUG: assurance failed:
 > tok.skip(WellKnownUrlPathPrefix())

 > Request:
 > GET cache_object://squid_ip/info HTTP/1.0
 > Host: squid_ip
 > User-Agent: squidclient/4.6
 > Accept: */*
 > Connection: close

Thank you for sharing this detail. I can now reproduce this problem.

You are suffering from a bug in Squid v6.3 commit 6695897 (which was
incorrectly attributed to me). Until that bug is addressed, cache
manager requests using the deprecated cache_object scheme (e.g., those
emitted by older squidclients) will trigger the above
WellKnownUrlPathPrefix assertion in Squid v6.3.

I have attached a patch that fixes this v6.3 bug in my tests.


 > Sending HTTP request ...
 > done.
 > HTTP/1.1 404 Not Found
 > Server: squid
 > Mime-Version: 1.0
 > Date: Tue, 12 Sep 2023 19:09:41 GMT
 > Content-Type: text/html;charset=utf-8
 > Content-Length: 13057
 > X-Squid-Error: ERR_INVALID_URL 0
 > Cache-Status: proxy;detail=no-cache
 > Via: 1.1 proxy (squid)
 > Connection: close
 >
 > This is obviously calling for url cache_object://squid_ip/info which I
 > think is obsolete. Now I went with the new squidclient:
 >
 > ./squidclient -h squid_ip -p squid_port -vv mgr:info
 >
 > Request:
> GET http://squid_ip:squid_port/squid-internal-mgr/info <http://squid_ip:squid_port/squid-internal-mgr/info> HTTP/1.0
 > Host: 10.50.1.5:3127
 > User-Agent: squidclient/6.3
 > Accept: */*
 > Connection: close

 > But it seems squid is then trying to open it's
 > visible_hostname:squid_port/squid-internal-mgr/ and due my DNS setting
 > it is its WAN IP - so it's connecting to its outside IP with its outside
 > IP which is not in the http_access manager allow list (now it is and the
 > newer squidclient works).

You are in Squid Bug 5283 territory here:
https://bugs.squid-cache.org/show_bug.cgi?id=5283 <https://bugs.squid-cache.org/show_bug.cgi?id=5283>

In a Linux test environment, I can work around those "outside IP"
problems by adding "-l 127.0.0.1" option to squidclient, forcing
squidclient to connect to Squid from the loopback address. IIRC, that
"-l" trick does not work in environments that do not support
from-localhost connections to "outside IPs" on the same box (e.g., Windows).


HTH,

Alex.



 > -----Původní zpráva-----
 > Od: squid-users za uživatele Alex Rousskov
 > Odesláno: út 12.9.2023 19:28
 > Komu: squid-users@lists.squid-cache.org
 > Předmět: Re: [squid-users] Squid BUG: assurance failed:
 > tok.skip(WellKnownUrlPathPrefix())
 >
 > On 2023-09-12 13:06, Loučanský Lukáš wrote:
 >  > Is this anyhow interesting?
 >
 > Not really, IMO -- the problem happens earlier. I can confirm that you
 > are running v6.3-based code. Let's call that progress :-).
 >
 > Can you share the a _pointer_ to a compressed ALL,9 cache.log file while
 > reproducing the problem using a single transaction?
 >
> https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction <https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction> <https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction <https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction>>
 >
 > Alex.
 >
 >  >
 >  > 2023/09/12 18:47:04.267 kid4| 24,8| SBuf.cc(30) SBuf: SBuf15514952
 > created
 >  > 2023/09/12 18:47:04.267 kid4| 24,8| SBuf.cc(30) SBuf: SBuf15514953
 > created
 >  > 2023/09/12 18:47:04.267 kid4| 24,8| SBuf.cc(30) SBuf: SBuf15514954
 > created
 >  > 2023/09/12 18:47:04.267 kid4| 24,7| SBuf.cc(85) assign: assigning
 >  > SBuf15514952 from SBuf15514912
 >  > 2023/09/12 18:47:04.267 kid4| 24,8| SBuf.cc(38) SBuf: SBuf15514955
 >  > created from id SBuf15514915
 >  > 2023/09/12 18:47:04.267 kid4| 24,8| SBuf.cc(445) startsWith:
 >  > SBuf15514955 startsWith SBuf125812, caseSensitive: 0
 >  > 2023/09/12 18:47:04.267 kid4| 24,8| SBuf.cc(447) startsWith: no, too
 > short
 >  > 2023/09/12 18:47:04.267 kid4| 24,8| Tokenizer.cc(185) skip: no match,
 >  > not skipping '/squid-internal-mgr/'
 >  > 2023/09/12 18:47:04 kid4| ERROR: Squid BUG: assurance failed:
 >  > tok.skip(WellKnownUrlPathPrefix())
 >  > 2023/09/12 18:47:04.268 kid4| 24,8| SBuf.cc(70) ~SBuf: SBuf15514955
 >  > destructed
 >  >
 >  >
 >  > BTW debug 24,9 makes pretty big log files... :-)
 >  >
 >  > L
 >  >
 >
 >
 > _______________________________________________
 > squid-users mailing list
 > 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
commit 381f130
Author: Alex Rousskov <rouss...@measurement-factory.com>
Date:   Thu Sep 14 17:50:10 2023 -0400

    Work around "TheRoot" assertions after shutdown
    
    Deleting complex objects like Stores and StoreEntries after main() is
    wrong. We probably want to delete (safely, before the end of main())
    those StoreEntries that are no longer in use. We do want to delete
    Stores before main() is over (but still leave TheRoot in a minimally
    functioning state instead of deleted!). This hack does none of that.

diff --git a/src/store/Controller.cc b/src/store/Controller.cc
index 66147a6..caa9757 100644
--- a/src/store/Controller.cc
+++ b/src/store/Controller.cc
@@ -47,10 +47,12 @@ Store::Controller::~Controller()
     delete transients;
     delete swapDir;
 
     if (store_table) {
-        hashFreeItems(store_table, destroyStoreEntry);
-        hashFreeMemory(store_table);
+        // XXX: Cannot destroy MemObjects that still have locks on entries in
+        // stores deleted above!
+        // hashFreeItems(store_table, destroyStoreEntry);
+        // hashFreeMemory(store_table);
         store_table = nullptr;
     }
 }
 
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Reply via email to