CISOfy
systemd Plugin tests get stuck on Debian 12
Describe the bug
Just cloned the repo and started the programm as described in the readme. All goes will till the Plugin: systemd starts. Then it just hangs indefinitely (waited for 15+ min without any response)
Version Program version: 3.1.2 Operating system: Linux Operating system name: Debian Operating system version: 12 Kernel version: 6.1.0 Hardware platform: x86_64
Expected behavior
Some kind of timeout or at least an info which test is currently being processed would be nice to give more information. Even adding the --verbose option to the command doesn't provide the information what test is currently run.
Output
root➜~/lynis(master)» ./lynis audit system --verbose
[ Lynis 3.1.2 ]
################################################################################
Lynis comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under the terms of the GNU General Public License.
See the LICENSE file for details about using this software.
2007-2021, CISOfy - https://cisofy.com/lynis/
Enterprise support available (compliance, plugins, interface and tools)
################################################################################
[+] Initializing program
------------------------------------
- Detecting OS... [ DONE ]
- Checking profiles... [ DONE ]
---------------------------------------------------
Program version: 3.1.2
Operating system: Linux
Operating system name: Debian
Operating system version: 12
Kernel version: 6.1.0
Hardware platform: x86_64
Hostname: --redacted--
---------------------------------------------------
Profiles: /root/lynis/default.prf
Log file: /var/log/lynis.log
Report file: /var/log/lynis-report.dat
Report version: 1.0
Plugin directory: ./plugins
---------------------------------------------------
Auditor: [Not Specified]
Language: en
Test category: all
Test group: all
---------------------------------------------------
- Program update status... [ NO UPDATE ]
[+] System tools
------------------------------------
- Scanning available tools...
- Checking system binaries...
[+] Program Details
------------------------------------
- Verbose mode [ YES ]
- Debug mode [ NO ]
[+] Plugins (phase 1)
------------------------------------
Note: plugins have more extensive tests and may take several minutes to complete
- Plugin: pam
[..]
- Plugin: systemd
[........
It gets to that state in a few seconds and then just hangs.
Additional context
/var/log/lynis.log
2024-03-21 15:33:09 Result: found machine ID: 516ab200e3f3410ba2cb97561e517f56
2024-03-21 15:33:09 ====
2024-03-21 15:33:09 Performing test ID PLGN-3810 (Query main systemd binaries)
2024-03-21 15:33:09 Result: found systemd binaries in /usr/lib/systemd
2024-03-21 15:33:09 ====
2024-03-21 15:33:09 Performing test ID PLGN-3812 (Query journal for boot related information)
2024-03-21 15:33:09 Output: number of boots listed in journal is 2
2024-03-21 15:33:09 Output: oldest boot date in journal is FIRST
2024-03-21 15:33:09 ====
2024-03-21 15:33:09 Performing test ID PLGN-3814 (Verify journal integrity)
As it seems the command journalctl --verify doesn't finish for me...
It just hangs there forever...
Doing a journalctl --vacuum-time=3weeks helped getting rid of old, unnecessary journal files.
With that out of the way the lynis runs through 🥳
That is also why Lynis hangs. Could be corruption of your journal, or its size. So it would be good to find out why it is stuck (e.g. by using strace)
Oh, while typing, you already found it :-D
Actually, it's great and a shame that you cleaned things up. Would have been great if we can find out how to discover the amount of time of journals it has and then check that first before doing the verification check.
By any chance got that command and time to test it?
damn... I am too fast 😂 Well I do have backups of my server so it shouldn't be a problem to just restore those journal files and test again
root➜~» journalctl --disk-usage [16:15:56]
Archived and active journals take up 1.9G in the file system.
It's a lot to parse, but at the same time not huge. Big question is if it really is getting stuck, or simply takes an insane amount of time to process.
Is the first, let's say 70%, going quick and then suddenly it stays stuck?
It takes about 2m 30sec to parse 1 journal file with 128MB.
I checked htop and it seems this tool is single threaded so only one of my available CPU cores is at 100% doing this.
The problem is just that - as established before - I have a bunch of journal files (like 48) all having 128MB.