to Adolf Belka: I´am not sure - sounds like the same but my errors are new (for me and I use ipfire more than 5 years) and not really at machine startup - I get it (this case) 10 hours after reboot and 4 hours after first active use.
in the cache.log I found this (perhaps this signs to a bug?).
May 10 10:41:08 squid-asnbl-helper[6443] INFO: queried destination ‘%5Bff00::%5D’ is neither a valid FQDN nor an IP address, returning ‘ERR’
May 10 10:41:08 squid-asnbl-helper[3878] WARN: No ASNBL configured. This is acceptable as long as this script is configured to do anything, you just have been warned…
May 10 10:41:08 squid-asnbl-helper[3878] INFO: ASN database operational - excellent. Waiting for input…
May 10 10:41:08 squid-asnbl-helper[3879] WARN: No ASNBL configured. This is acceptable as long as this script is configured to do anything, you just have been warned…
May 10 10:41:08 squid-asnbl-helper[3879] INFO: ASN database operational - excellent. Waiting for input…
May 10 10:41:08 squid-asnbl-helper[3879] INFO: queried destination ‘%5Bff00::%5D’ is neither a valid FQDN nor an IP address, returning ‘ERR’
May 10 10:41:08 squid-asnbl-helper[3891] WARN: No ASNBL configured. This is acceptable as long as this script is configured to do anything, you just have been warned…
May 10 10:41:08 squid-asnbl-helper[3891] INFO: ASN database operational - excellent. Waiting for input…
May 10 10:41:08 squid-asnbl-helper[3890] WARN: No ASNBL configured. This is acceptable as long as this script is configured to do anything, you just have been warned…
May 10 10:41:08 squid-asnbl-helper[3890] INFO: ASN database operational - excellent. Waiting for input…
May 10 10:41:08 squid-asnbl-helper[3890] INFO: queried destination ‘%5Bff00::%5D’ is neither a valid FQDN nor an IP address, returning ‘ERR’
May 10 10:41:08 squid-asnbl-helper[3900] WARN: No ASNBL configured. This is acceptable as long as this script is configured to do anything, you just have been warned…
May 10 10:41:08 squid-asnbl-helper[3900] INFO: ASN database operational - excellent. Waiting for input…
May 10 10:41:08 squid-asnbl-helper[3901] WARN: No ASNBL configured. This is acceptable as long as this script is configured to do anything, you just have been warned…
May 10 10:41:08 squid-asnbl-helper[3901] INFO: ASN database operational - excellent. Waiting for input…
May 10 10:41:09 squid-asnbl-helper[3900] INFO: queried destination ‘%5Bff00::%5D’ is neither a valid FQDN nor an IP address, returning ‘ERR’
May 10 10:41:09 squid-asnbl-helper[3910] WARN: No ASNBL configured. This is acceptable as long as this script is configured to do anything, you just have been warned…
May 10 10:41:09 squid-asnbl-helper[3910] INFO: ASN database operational - excellent. Waiting for input…
May 10 10:41:09 squid-asnbl-helper[3911] WARN: No ASNBL configured. This is acceptable as long as this script is configured to do anything, you just have been warned…
May 10 10:41:09 squid-asnbl-helper[3911] INFO: ASN database operational - excellent. Waiting for input…
May 10 10:41:09 squid-asnbl-helper[3910] INFO: queried destination ‘%5Bff00::%5D’ is neither a valid FQDN nor an IP address, returning ‘ERR’
May 10 10:41:09 squid-asnbl-helper[3923] WARN: No ASNBL configured. This is acceptable as long as this script is configured to do anything, you just have been warned…
May 10 10:41:09 squid-asnbl-helper[3923] INFO: ASN database operational - excellent. Waiting for input…
May 10 10:41:09 squid-asnbl-helper[3922] WARN: No ASNBL configured. This is acceptable as long as this script is configured to do anything, you just have been warned…
May 10 10:41:09 squid-asnbl-helper[3922] INFO: ASN database operational - excellent. Waiting for input…
May 10 10:41:09 squid-asnbl-helper[3922] INFO: queried destination ‘%5Bff00::%5D’ is neither a valid FQDN nor an IP address, returning ‘ERR’
so, signal 6 is SIGABRT, which is apparently sent by some component to Squid, causing it to terminate.
Your problem sounds related to this one, which I currently don’t know what it is caused by. In your case, I am suspecting SquidClamAV to be the root cause - does disabling it make a difference?
The ASNBL helper messages are normal and do not indicate a problem.
Well, I guess we should really drop SquidClamAV. It is causing more and more trouble, has no meaning in a world where everything is HTTPS, and is upstream dead for a long time (and smelling).
I’m also effected. Just found this here because the webproxy stopped working. And yes I also run Squidclamav.
|14:29:29|squid[5716]: |Squid Parent: squid-1 process 5718 exited due to signal 6 with status 0|
|14:29:29|squid[5716]: |Squid Parent: (squid-1) process 10321 started|
|14:29:30|squid[5716]: |Squid Parent: squid-1 process 10321 exited due to signal 6 with status 0|
|14:29:30|squid[5716]: |Squid Parent: (squid-1) process 10336 started|
|14:29:32|squid[5716]: |Squid Parent: squid-1 process 10336 exited due to signal 6 with status 0|
|14:29:32|squid[5716]: |Squid Parent: (squid-1) process 10350 started|
|14:29:36|squid[5716]: |Squid Parent: squid-1 process 10350 exited due to signal 6 with status 0|
|14:29:36|squid[5716]: |Squid Parent: (squid-1) process 10364 started|
|14:29:37|squid[5716]: |Squid Parent: squid-1 process 10364 exited due to signal 6 with status 0|
|14:29:37|squid[5716]: |Squid Parent: (squid-1) process 10378 started|
|14:29:39|squid[5716]: |Squid Parent: squid-1 process 10378 exited due to signal 6 with status 0|
|14:29:39|squid[5716]: |Squid Parent: squid-1 process 10378 will not be restarted for 3600 seconds due t o repeated, frequent failures|
|14:29:39|squid[5716]: |Exiting due to repeated, frequent failures|
The first bit may well be true but the second bit is not. IPFire currently has version 5.11 which is from 2012 but the latest version is 7.1 from March 2019 and there were two commits in Aug 2021 and one in May 2022 so not totally dead.
I will look at building and submitting an update patch for it. While it is still in place we should have the latest version running.
I have had a look at the updated versions reading through the changes and I may have found out why it has not been updated yet.
The move to version 6.0 from 5.11 was a very major change. From that version onwards squidclamav uses the ICAP protocol and must be run as a c-icap server service.
I can probably do a build of the newer squidclamav but I have no way to test out if it is working as I don’t use squidclamav or clamav on my testbed vm that I use for evaluating new changes.
I suspect that an update of squidclamav need to be built and tested out by someone who is using squidclamav and knows how to set it up and how to tell if it is working.
I suspect that no one in the dev team is using squidclamav and so far no one using squidclamav has been willing or able to do the build and evaluation and that is why it is still at the 5.11 version.
A definite question here is if it is worth doing that building and evaluation work with the significant change in operation between the 5.x and 6.x version series and especially as it can only work with any websites that are running http and not https.
Indeed, the shift towards ICAP is a major change, and a good thing in technical terms, as ICAP is a more mature protocol for doing content scanning with Squid in particular and other applications in general.
Frankly, however, I do not think it is worth the effort to start working on this in IPFire 2.x: Too many changes are required under the hood, and as you already stated, we do not have a good userbase for this, especially among IPFire developers.
Therefore, I would vote for leaving SquidClamAV for the time being, and rather spend our (your) efforts on more important topics, such as maintaining IPFire 2.x as a whole or developing IPFire 3.x, as soon as the Pakfire build service for it is ready to be used. (https://pakfire.ipfire.org/ is somewhat back again, and I am excited to hear some news from that ecosystem in the upcoming telephone conference.)
