What happened
All ext-iscsid service log lines (from the iscsi-tools extension) are tagged talos-level: info, regardless of actual severity. Genuine iSCSI errors are indistinguishable from routine info in talosctl logs ext-iscsid and in shipped logs (machine.logging).
Examples that appear at info:
iscsid: connection2:0 login rejected: initiator error - target not found (02/03)
iscsid: Kernel reported iSCSI connection 2:0 error (1020 - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (1)
Why
iscsid writes plain text to stdout/stderr with no severity prefix. Talos populates talos-level from the service output; with no severity present it defaults to info. Talos's own services (machined, apid) and kernel logs carry real severity, so this is specific to extension services that emit unstructured output.
Impact
Severity-based filtering/alerting on logs can't surface iSCSI failures — a persistent login/connection error loop is invisible unless you grep message text. Consumers are forced into brittle keyword parsing downstream to recover severity.
Request
Have the iscsi-tools extension run iscsid so severity is preserved — e.g. configure it to log via syslog (with priorities) that Talos can map, rather than bare stdout. If that's not feasible in the extension alone, this may need Talos-side support for mapping extension-service severity; happy to cross-file against siderolabs/talos if preferred.
Environment
- Talos v1.13.7,
iscsi-tools extension (as shipped via image factory)
- democratic-csi driving iSCSI against TrueNAS
What happened
All
ext-iscsidservice log lines (from theiscsi-toolsextension) are taggedtalos-level: info, regardless of actual severity. Genuine iSCSI errors are indistinguishable from routine info intalosctl logs ext-iscsidand in shipped logs (machine.logging).Examples that appear at
info:Why
iscsidwrites plain text to stdout/stderr with no severity prefix. Talos populatestalos-levelfrom the service output; with no severity present it defaults toinfo. Talos's own services (machined, apid) and kernel logs carry real severity, so this is specific to extension services that emit unstructured output.Impact
Severity-based filtering/alerting on logs can't surface iSCSI failures — a persistent login/connection error loop is invisible unless you grep message text. Consumers are forced into brittle keyword parsing downstream to recover severity.
Request
Have the
iscsi-toolsextension runiscsidso severity is preserved — e.g. configure it to log via syslog (with priorities) that Talos can map, rather than bare stdout. If that's not feasible in the extension alone, this may need Talos-side support for mapping extension-service severity; happy to cross-file againstsiderolabs/talosif preferred.Environment
iscsi-toolsextension (as shipped via image factory)