[squid-users] squid 5.3 frequent crash

[Majed Zouhairy]

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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users