On Wed, 23 Oct 2024 15:07:10 +0200, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2024-10-23 10:03, Stakanov via openSUSE Users wrote:
silversurfer:~ # journalctl -t clamd |sed -n -e "1,\\|$SPAM_re|p"
Oct 19 10:15:52 silversurfer clamd[2059]: File path check failure on: /home/ mercurio/.local/share/local-mail/solucion freenet/cur/ 1619518303440.R45.silversurfer:2,S sed: -e expression #1, char 0: no previous regular expression
Did you define $SPAM_re in advance?
Right. Due to $SPAM_re being unset, sed sees an empty regex between the delimiters and expects to use the previous one. So sed starts printing on line 1 and then fails on input line 2 when it first tries matching the regex. That being the first line output from 'journalctl -t clamd' means there are no clamd entries preceding the File path check failures. The file path and pid here vary from the previous examples given by Stakanov such that $SPAM_re needs updating to match the whole set: PID_re='[0-9]\+' PATH_re='/home/mercurio/.*' SPAM_re=' silversurfer clamd\['"$PID_re"'\]: File path check failure for: '"$PATH_re"'$'
This is the first entry where it does not find a path. So this by itself is interesting indeed, because local-mail solucion in mercurio is an account that has been eliminated time ago(!), no wonder that it does not find its path. Question is, if I did eliminate this entry in kmail time ago, why and where is there a path hanging around in the home directory leading to clamd searching for it?
There was once a kind of cleaner program in kde, does it still work? Maybe I should run it? The home directory of this system is historical and survived about 10 re-installations during the years. Email changed, usages changed, so obviously clutter may be there around.
Just use a file browser as root (I recommend 'mc' in a terminal) and navigate to /home/mercurio/.local/share/local-mail/
-- Robert Webb