On 2024-11-21 07:29, Matus UHLAR - fantomas wrote:
I run squid 6 (currently 6.10) on some debian hosts.
when rotating logs in the night, I get mail about cron output:
2024/11/21 00:00:41| Processing Configuration File:
/etc/squid/squid.conf (depth 0)
2024/11/21 00:00:41| Processing Configuration File:
/etc/squid/conf.d/debian.conf (depth 1)
2024/11/21 00:00:41| Processing Configuration File:
/etc/squid/conf.d/ftplog.conf (depth 1)
2024/11/21 00:00:41| Set Current Directory to /var/spool/squid
This did not happen with squid-5.7
- is this a bug or a new feature?
IIRC, it is a side effect of a bug fix (or a series of bug fixes, to
be more precise). Earlier, such messages were dropped or went to
cache.log (violating locking rules and messing up triage of other
complicated bugs and misconfigurations).
Those messages are sent to stderr, not stdout. I can imply redirect
the "squid -k rotate" stderr to /dev/null
but I would like to avoid it when possible - if any error happens,
I't like to know about that.
On 21.11.24 16:16, Alex Rousskov wrote:
If you are OK with not seeing these particular messages in cache.log
and on stderr, disable their level-1 reporting using cache_log_message
directive. The ID of those messages is 68 (see doc/debug-messages.dox
for IDs of other messages that can be controlled in your Squid).
Only cache.log would be ideal. However, the description at
http://www.squid-cache.org/Doc/config/cache_log_message/ is not clear enough
what exactly that level means, and unfortunately you didn't make id more
clear.
(the page is mentioning doc/debug-messages.txt btw)
Do I understand it properly that level 1 goes to stderr+cache.log and level
2 nowhere?
For example:
cache_log_message id=68 level=2
IIRC: Core developers failed to reach consensus regarding the best
level for these messages, so their original "important" level (1) was
preserved. The argument was "folks are quite often mistaken regarding
what configuration files their Squids are actually using".
That makes sense, kinda.
If you want Squid to only report errors to stderr, then you will need
to wait for (or orchestrate) the corresponding code changes.
Currently, Squid defines error as a message with an ERROR: or FATAL:
prefix. There is no Squid code to treat such messages specially though
(yet?). For more details, please see https://github.com/squid-cache/squid/commit/d816f28de8ba817a98a49f9cfd88ddaa334d7aad
You may be able to emulate the above error detection/handling
(including its risks related to incorrectly unclassified/unprefixed
messages) via a shell script. For example, something like this might
be a good starting point:
squid -k rotate |& grep -E "FATAL:|ERROR:"
or, with added logging of all stderr messages:
squid -k rotate |& \
tee squid-last-rotate.log | \
grep -E "FATAL:|ERROR:"
However, the above sketches need more work/adjustments to preserve
"squid -k rotate" exit status code!
--
Matus UHLAR - fantomas, uhlar@xxxxxxxxxxx ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
M$ Win's are shit, do not use it !
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
