Il Sun, Dec 17, 2023 at 09:52:53PM +0000, Richard Lewis scrisse: Apologise me....
During this morning, for every test logcheck sent me the email. This times, also without the -l option, I saw the logs so I waited the cron if something was changed. The logs lines there are, but after the header I see many blank lines: I use mutt in a full screen console (more than 50 lines) and I need to press page down for 16 times before reach the first line of logs (in the last one email). So I suppose that in this days the logs there have been, but I never thought to press page down :( Now the question may be: why I have tens of blank lines? Is it mutt? Down I leave anyway the answers I wrote before find the blank lines just to completion your questions. If you think, close the bug. Sorry and thanks for your time. Stefano > On Sun, 17 Dec 2023 at 19:03, Stefano Callegari > <ste.calleg...@tiscali.it> wrote: > > Il Fri, Dec 15, 2023 at 11:31:18PM +0000, Richard Lewis scrisse: > > > On Fri, 15 Dec 2023 at 16:06, Stefano Callegari > > > <ste.calleg...@tiscali.it> wrote: > > > > > > > from few days the email from cron are empty, there is only the > > > > header.txt. > > > > > > > /etc/logcheck <-bash> # su -s /bin/bash -c "/usr/sbin/logcheck -l > > > > /var/log/syslog" logcheck > > > > > > > > the email has the log lines. Without the -l option, still empty. > > > > > > Seems like it isnt checking the syslog -- what is in the files in > > > /etc/logcheck/logcheck.logfiles.d/ and logcheck.conf ? > > > > > ~ <-bash> # ls /etc/logcheck/logcheck.logfiles.d/ > > journal.logfiles syslog.logfiles > > [snip] -- everything you posted looked fine and standard to me: it > should be checking both syslog and the journal as expected > > The only other thing you didn't include is a check of the permissions: > there was a change in bookworm - i doubt that > this is the issue, but for completeness: > > the directory /etc/logcheck should be owned by logcheck:logcheck and > permissions: drwxr-x--- > the contents should all be root:root and usual permissions, ie > -rw-r--r-- (with subdirectories drwxr-xr-x) > > (as long permissions allow logcheck to read everything, it should all be fine) The permissions are exactly like those. > > > > I suggest also using the -d option -- should say what it is doing in > > > great detail (pipe to file or through less) > > > > I've tried! Many and many of lines, never ending, it seems a loop. I had to > > do a ^C. > > Interesting - that definitely shouldnt happen, and '-d' shouldn't be > doing anything 'extra' to cause that (is it definitely a loop or just > looking like one because if your log contains lines that dont match > any rules (will be reported in the email), logcheck has to check every > single rules file, and -d will tell you the results before and after > each rule file it uses: so it should look like it's printing the same > output many times. to minimise the output, you can run once without > -d, then do a 'logger foo' to ensure there's at lease one new line in > the log and then re-run with -d) Ok... I've tried with a "clean" logcheck, than 'logger foo' and logcheck with -d. The time are faster, but no redirect ( ... > file) nor less ( ... | less) save the output of logcheck (that instead I see on console). > > The only potential for a loop that i can immediately think of would be > if you had some kind of symlink loop in the rules directory - do you > have any symlinks in the ignore.d.server or similar dirs (check with > ls -laR) > 'ls -laR ignore.d.*' don't show symlink. > i didnt think that could happen, i've no idea if logcheck would cope > with that or not > > Can you provide the start of the -d output /enough to understand what > the loop is? Otherwise, the start of the output should say what files > it was checking, unfortunately, if there's an issue sending the issue, > it likely wont be obvious until the very end. As wrote over I can't "save" the output, but ^S and ^Q give me an help... (don't consider the date because I exec logcheck more times to save with copy&paste) /etc/logcheck <-bash> # su -s /bin/bash -c "/usr/sbin/logcheck -d" logcheck DEBUG: [lun 18 dic 2023, 12:42:31, CET] Turning debug mode on DEBUG: [lun 18 dic 2023, 12:42:31, CET] Sourcing - /etc/logcheck/logcheck.conf DEBUG: [lun 18 dic 2023, 12:42:31, CET] Finished getopts c:dhH:l:L:D:m:opr:RsS:tTuvw DEBUG: [lun 18 dic 2023, 12:42:31, CET] Using rules from the following REPORTLEVELs: server paranoid DEBUG: [lun 18 dic 2023, 12:42:31, CET] Setting lockfile: /run/lock/logcheck/logcheck.lock DEBUG: [lun 18 dic 2023, 12:42:31, CET] Running lockfile-touch /run/lock/logcheck/logcheck.lock DEBUG: [lun 18 dic 2023, 12:42:31, CET] Using working dir: /tmp/logcheck.OBHh22 DEBUG: [lun 18 dic 2023, 12:42:31, CET] cleanrules /etc/logcheck/cracking.d => /tmp/logcheck.OBHh22/cracking DEBUG: [lun 18 dic 2023, 12:42:31, CET] cleanrules: /etc/logcheck/cracking.d/kernel -> /tmp/logcheck.OBHh22/cracking/kernel DEBUG: [lun 18 dic 2023, 12:42:31, CET] cleanrules: /etc/logcheck/cracking.d/rlogind -> /tmp/logcheck.OBHh22/cracking/rlogind [... a serie of cleanrules: ...] DEBUG: [lun 18 dic 2023, 12:48:13, CET] cleanrules: /etc/logcheck/ignore.d.paranoid/usb -> /tmp/logcheck.TqlJ8Y/ignore/usb DEBUG: [lun 18 dic 2023, 12:48:13, CET] logoutput called with file: journal DEBUG: [lun 18 dic 2023, 12:48:13, CET] Running journalctl -q --since=@1702899989 DEBUG: [lun 18 dic 2023, 12:48:13, CET] logoutput called with file: /var/log/syslog DEBUG: [lun 18 dic 2023, 12:48:14, CET] Running /usr/sbin/logtail2 on /var/log/syslog DEBUG: [lun 18 dic 2023, 12:48:14, CET] logoutput called with file: /var/log/auth.log DEBUG: [lun 18 dic 2023, 12:48:14, CET] Running /usr/sbin/logtail2 on /var/log/auth.log DEBUG: [lun 18 dic 2023, 12:48:14, CET] Sorting logs DEBUG: [lun 18 dic 2023, 12:48:14, CET] After sorting, we have the following log entries to check --- START [ /tmp/logcheck.TqlJ8Y/logoutput-sorted (LINES: 97) ] --- [... log lines ...] dic 18 12:48:10 G5045 irqbalance[5452]: --- END [ /tmp/logcheck.TqlJ8Y/logoutput-sorted (LINES: 97) ] --- DEBUG: [lun 18 dic 2023, 12:48:14, CET] Adding a header to the report --- START [ /etc/logcheck/header.txt (LINES: 4) ] --- This email is sent by logcheck. If you no longer wish to receive such mail, you can either uninstall the logcheck package or modify its configuration file (/etc/logcheck/logcheck.conf). --- END [ /etc/logcheck/header.txt (LINES: 4) ] --- DEBUG: [lun 18 dic 2023, 12:54:10, CET] Checking for cracking alerts (Security Alerts) using cracking.d DEBUG: [lun 18 dic 2023, 12:54:10, CET] greplogoutput (/tmp/logcheck.TqlJ8Y/cracking Security Alerts): Starting DEBUG: [lun 18 dic 2023, 12:54:10, CET] greplogoutput: Using /tmp/logcheck.TqlJ8Y/cracking/kernel to find entries to report --- START [ /tmp/logcheck.TqlJ8Y/cracking/kernel (LINES: 1) ] --- kernel: Oversized packet received from --- END [ /tmp/logcheck.TqlJ8Y/cracking/kernel (LINES: 1) ] --- [... cut here ...] Unfortunately I tried many way to store the output, but notin to do. I hope the few line over help you. > > the only other thing i can think of is a disk space issue (i could > imaging bad things happening if /tmp was full, or wherever the mta > stores the email - /var or similar) A full disk/partition was a doubt that I check immediately. > > (you could email it to me if you want to avoid it appearing in the > public bts - up to you: i wouldnt expect there to be anything too > sensitive in the logs, but i suppose we cant rule that out). Thanks -- Stefano Callegari GnuPG Public Key Server: pgp.mit.edu
