now on 5.4 i get:
2022/02/14 15:14:32 kid1| FATAL: Unable to open HTTP Socket
2022/02/14 15:14:32 kid1| Squid Cache (Version 5.4): Terminated abnormally.
CPU Usage: 0.401 seconds = 0.357 user + 0.044 sys
Maximum Resident Size: 101920 KB
Page faults with physical i/o: 0
2022/02/14 15:14:32 kid1| Closing Pinger socket on FD 46
2022/02/14 15:14:32| pinger: Initialising ICMP pinger ...
2022/02/14 15:14:32| pinger: ICMP socket opened.
2022/02/14 15:14:32| pinger: ICMPv6 socket opened
2022/02/14 15:14:32| Pinger exiting.
2022/02/14 15:14:32 kid1| ERROR: negotiating TLS on FD 116:
error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed
(1/-1/0)
2022/02/14 15:14:32 kid1| Set Current Directory to /var/cache/squid
2022/02/14 15:14:32 kid1| Starting Squid Cache version 5.4 for
x86_64-suse-linux-gnu...
2022/02/14 15:14:32 kid1| Service Name: squid
2022/02/14 15:14:32 kid1| Process ID 19350
2022/02/14 15:14:32 kid1| Process Roles: worker
2022/02/14 15:14:32 kid1| With 4096 file descriptors available
2022/02/14 15:14:32 kid1| Initializing IP Cache...
2022/02/14 15:14:32 kid1| DNS Socket created at [::], FD 8
2022/02/14 15:14:32 kid1| DNS Socket created at 0.0.0.0, FD 9
2022/02/14 15:14:32 kid1| Adding nameserver 10.0.10.15 from /etc/resolv.conf
2022/02/14 15:14:32 kid1| Adding nameserver 10.0.10.14 from /etc/resolv.conf
2022/02/14 15:14:32 kid1| helperOpenServers: Starting 5/32
'security_file_certgen' processes
2022/02/14 15:14:32 kid1| helperOpenServers: Starting 8/16 'ufdbgclient'
processes
2022/02/14 15:14:33 kid1| Logfile: opening log
daemon:/var/log/squid/access.log
2022/02/14 15:14:33 kid1| Logfile Daemon: opening log
/var/log/squid/access.log
2022/02/14 15:14:33 kid1| ERROR: negotiating TLS on FD 161:
error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed
(1/-1/0)
2022/02/14 15:14:33 kid1| Unlinkd pipe opened on FD 41
2022/02/14 15:14:33 kid1| Local cache digest enabled; rebuild/rewrite
every 3600/3600 sec
2022/02/14 15:14:33 kid1| Store logging disabled
2022/02/14 15:14:33 kid1| Swap maxSize 3072000 + 983040 KB, estimated
311926 objects
2022/02/14 15:14:33 kid1| Target number of buckets: 15596
2022/02/14 15:14:33 kid1| Using 16384 Store buckets
2022/02/14 15:14:33 kid1| Max Mem size: 983040 KB
2022/02/14 15:14:33 kid1| Max Swap size: 3072000 KB
2022/02/14 15:14:33 kid1| Rebuilding storage in /var/cache/squid (dirty log)
2022/02/14 15:14:33 kid1| Using Least Load store dir selection
2022/02/14 15:14:33 kid1| Set Current Directory to /var/cache/squid
2022/02/14 15:14:33 kid1| Finished loading MIME types and icons.
2022/02/14 15:14:33 kid1| commBind Cannot bind socket FD 44 to
[::]:8080: (98) Address already in use
2022/02/14 15:14:33 kid1| HTCP Disabled.
2022/02/14 15:14:33 kid1| Pinger socket opened on FD 46
2022/02/14 15:14:33 kid1| Squid plugin modules loaded: 0
2022/02/14 15:14:33 kid1| Adaptation support is off.
2022/02/14 15:14:33 kid1| Closing HTTP(S) port [::]:8080
2022/02/14 15:14:33 kid1| Not currently OK to rewrite swap log.
2022/02/14 15:14:33 kid1| storeDirWriteCleanLogs: Operation aborted.
2022/02/14 15:14:33 kid1| FATAL: Unable to open HTTP Socket
2022/02/14 15:14:33 kid1| Squid Cache (Version 5.4): Terminated abnormally.
On 1/18/22 23:56, Alex Rousskov wrote:
On 1/18/22 2:51 AM, Amos Jeffries wrote:
On 8/01/22 05:02, Alex Rousskov wrote:
On 1/7/22 9:34 AM, Amos Jeffries wrote:
Others include altering the fundamental AsyncJob API behaviour -
affecting every feature in Squid at their most fundamental levels.
I disagree with the above summary.
This is not an opinion.
It is impossible to tell for sure whether this is an opinion or a fact
because the summary is using undefined terms like "every feature" and
"most fundamental levels". To you, it may sound like a fact. To me, it
sounds like gross exaggeration at best: Clearly, there are Squid
features (for some reasonable definition of a "feature") unaffected by
this change at "most fundamental levels" (for some reasonable definition
of "most fundamental levels").
The patch "part 2" makes logic changes to
AsyncJob - specifically destructors and swanSong. That touches
*everything* Squid does. The other parts touch I/O in similarly deep
ways and we have a history of unexpected weird side effects with I/O
refactorings.
I do not think squid-users is the right place to debate complex
development issues. I will just note that the commit in question does
not, IMO, change AsyncJob methods in fundamental ways. It only shrinks
the long-known gray area of what those functions should (not) do. Before
this change, we did not know where certain actions should take place.
Now, we (think we) do, and we have adjusted a few places to follow those
newly discovered rules.
Will this complex change have unexpected side effects? Yes, of course! I
have disclosed that risk when posting the changes. No need to grossly
exaggerate to agree on that point -- nobody is arguing against it.
I am seriously considering using our exceptional beta release process
for these changes once v5.4 bug fixes are out.
FWIW, I see no need for a special process here. We have no reasons to
believe that the change is making Squid v5 worse overall. All those who
tested the change in v5 and master reported significant improvement in
Squid stability. Moreover, since the last numbered v5 release was
unstable (for many reasons), the bar for the next numbered v5 release is
pretty low: We are not going from very stable to possibly unstable; we
are going from very unstable to possibly less unstable.
Said that, I am not trying to block the "exceptional beta release
process" you want to use. I am just providing feedback. Most v5 actions
are your call as a v5 maintainer, including special v5.x.y snapshots
that have three numbers instead of the usual two.
IMO the best code to base your backport PR on would be the v5 HEAD after
1st Feb when I post the "prep for 5.4" or similar QA for review.
To avoid misunderstanding, when you have a commit SHA that the backport
should be based on, please let me know that SHA, and I will start
backporting from that point. That commit/SHA does not have to be in the
official branch, of course.
That gives us 6 weeks for validation before v5.5 release decisions are
made. I seriously *hope* that is enough testing not to be hit later with
another one of these.
FWIW, all other factors being equal, I doubt you would see more "beta"
v5 testers than you would see without any special "beta" releases. If
anything, the opposite is probably true. That is one of the several
reasons I do not recommend using special procedures for releasing this
important bug fix in v5. Again, this is your call.
HTH,
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
