stamparm/maltrail · error · SystemExit
[!] no maltrail-sensor package entry found in
Error message
[!] no maltrail-sensor package entry found in %s
What it means
cargo_lock_version scans sensor/Cargo.lock for the `name = "maltrail-sensor"` package entry and its adjacent version line. If the lockfile has no such entry (stale lockfile, renamed package, or lockfile not regenerated after Cargo.toml changes), the tool exits with this message. This matters because release builds run with --locked, where an outdated lock would otherwise fail later and opaquely.
Solutions
- Run `cargo update --manifest-path sensor/Cargo.toml` (or `cargo generate-lockfile`) to regenerate Cargo.lock with the maltrail-sensor entry
- Confirm [package] name in sensor/Cargo.toml is exactly `maltrail-sensor` (lock entries must match)
- Ensure the [[package]] block has name and version on consecutive lines in the expected order
- Re-run check_version.py after the lockfile is refreshed
Example fix
// before (Cargo.lock missing entry) [[package]] name = "some-other-crate" // after [[package]] name = "maltrail-sensor" version = "3.2.1"
Defensive patterns
Strategy: validation
Validate before calling
import re, pathlib
text = pathlib.Path("sensor/Cargo.lock").read_text()
assert re.search(r'name = "maltrail-sensor"\nversion = "([^"]+)"', text), "Cargo.lock missing maltrail-sensor entry" Prevention
- Run cargo update after any Cargo.toml name/version change
- Commit Cargo.lock together with Cargo.toml changes
- Grep the lockfile in CI before release gates
When it happens
Trigger: Running check_version.py when Cargo.lock does not contain a [[package]] block with `name = "maltrail-sensor"` followed by `version = "..."` — e.g. the package was renamed in Cargo.toml, the lockfile was deleted/regenerated before the rename, or the lockfile predates the package.
Common situations: Renaming the crate during a refactor without regenerating Cargo.lock; checking out a branch where Cargo.lock is stale or missing the sensor entry; reverting Cargo.toml but not Cargo.lock (or vice versa).
Understand the failure class
Background: Record Not Found Errors: "not found", RecordNotFound, and "was not found" — what they mean and how to fix them — this error's family across 28 libraries.
Related errors
- [!] no VERSION constant found in
- [!] no version key found in
- [!] not built - cargo build --release --manifest-path…
- [x] invalid IP address
- not a Maltrail provenance sidecar (bad magic)
AI-assisted analysis of stamparm/maltrail@77cfb06d76 (2026-09-13).
Data as JSON: /api/errors/dee1c80a7210ba45.
Report an issue: GitHub.
Appendix: source
Thrown at sensor/tools/check_version.py:99
built. A version bump is text; verifying it should be text too.
"""
match = re.search(r'^pub const VERSION: &str = "([^"]+)";', _read(SETTINGS_GEN), re.M)
if not match:
raise SystemExit("[!] no VERSION constant found in %s" % SETTINGS_GEN)
return match.group(1)
def cargo_lock_version():
"""The maltrail-sensor entry in sensor/Cargo.lock.
A FIFTH place, and the release builds with --locked: a lock that still names the old version
does not warn, it refuses to build.
"""
match = re.search(r'name = "maltrail-sensor"\nversion = "([^"]+)"', _read(CARGO_LOCK))
if not match:
raise SystemExit("[!] no maltrail-sensor package entry found in %s" % CARGO_LOCK)
return match.group(1)
def series(version):
"""'3.0.1' and '3.0' both reduce to (3, 0) - Maltrail versions two components, Cargo three.
A SemVer pre-release / build suffix is stripped first, so 'v3.0-rc1' and '3.0.0+deb' are the
3.0 series like anything else. Release candidates are the whole point of having a release
pipeline that can be rehearsed, and refusing to name one would have made that impossible.
"""
version = re.split(r"[-+]", version, 1)[0]
parts = version.split('.')
if len(parts) < 2:
raise SystemExit("[!] version %r is not 'major.minor[.patch]'" % version)
try:
return (int(parts[0]), int(parts[1]))
except ValueError:
raise SystemExit("[!] version %r has non-numeric components" % version)View on GitHub (pinned to 77cfb06d76)