Journalctl logs not parsed - 0 lines parsed from 496k lines read on HAOS

[kingcodfish]

Environment:

• Home Assistant OS 17.2
• CrowdSec addon v1.7.7-981e6166
• Collections: crowdsecurity/home-assistant, crowdsecurity/linux, crowdsecurity/sshd

Problem:
With the default acquisition config (journalctl --directory=/var/log/journal/, type: syslog),
CrowdSec reads ~496k lines from the journal but parses 0 of them.

cscli metrics show acquisition output:
| Source | Lines read | Lines parsed |
| journalctl:journalctl---directory=/var/log/journal/ | 496.82k | - |

What I tried:

• _TRANSPORT=syslog filter returns an empty table (no matching entries in HAOS journal)
• home-assistant.log is not mounted into the CrowdSec container (find / returns nothing)
• The HA parser requires program field extracted by syslog raw parser, which never runs

Expected behaviour:
HA login failures should be detected by crowdsecurity/home-assistant-bf scenario.

Possible causes:

• HAOS journal format doesn't match the syslog-logs.yaml raw parser
• home-assistant.log is not bind-mounted into the container, making file-based acquisition impossible

[sabban]

Hi,

If the crowdsec reads ~496k lines from the journal but parses 0 of them, it has access to logs, so the issue is with how crowdsec reads logs: either the parser is faulty or there's an issue with the parser's configuration.

Can you share a bit of the logs that are being read but not parsed? So that I can check whether the CrowdSec parsers are working?

Thanks for your report,

Regards,

[kingcodfish]

Hi, thanks for looking into this.

Here are sample logs from the journal that CrowdSec is reading but not parsing:

May 20 08:34:34.753288 homeassistant homeassistant[505]: 2026-05-20 08:34:34.751 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from <redacted-rdns> (<redacted-ip>). Requested URL: '/auth/login_flow/553493e9535dc78679525c0a05b6a1dc'. (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0)
May 20 08:34:39.775677 homeassistant homeassistant[505]: 2026-05-20 08:34:39.774 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from <redacted-rdns> (<redacted-ip>). Requested URL: '/auth/login_flow/553493e9535dc78679525c0a05b6a1dc'. (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0)
May 20 08:34:43.098911 homeassistant homeassistant[505]: 2026-05-20 08:34:43.098 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from <redacted-rdns> (<redacted-ip>). Requested URL: '/auth/login_flow/553493e9535dc78679525c0a05b6a1dc'. (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0)
May 20 08:34:44.714247 homeassistant homeassistant[505]: 2026-05-20 08:34:44.713 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from <redacted-rdns> (<redacted-ip>). Requested URL: '/auth/login_flow/553493e9535dc78679525c0a05b6a1dc'. (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0)

After some digging I found a few things that seem to be causing the issue:

1. The default acquisition config reads the entire journal with type: syslog, but the HAOS journal format includes microsecond precision timestamps (e.g. 08:34:34.753288) which the syslog raw parser doesn't appear to handle, resulting in 0 lines parsed.

2. The HA container's SYSLOG_IDENTIFIER in the journal is simply homeassistant, not home-assistant or hass as the parser filter expects. Though this is moot if the syslog parser never successfully runs in the first place.

3. The acquisition config has no filter, so CrowdSec reads the entire system journal (~100k+ lines of Docker networking noise) instead of just the HA container logs.

I've worked around it by updating the acquisition config to filter by SYSLOG_IDENTIFIER=homeassistant, which at least gets the right logs in scope. But the syslog parser timestamp mismatch still needs a fix on the parser or acquisition side.

Happy to provide any additional information if helpful.