Lertick contains an experimental C/eBPF sched_ext CPU scheduler and privileged loader. Native installation, continuous foreground use and an opt-in systemd service are available; there is no supported production release. Installation alone does not start or enable the service. Keep an independent administrator terminal or console for a new-kernel run. The recorded runtime evidence comes from an Ubuntu ARM64 VM, not physical-hardware performance or long-term production measurements. See the exact deployment results and VM reproduction.
Use GitHub private vulnerability reporting for a suspected security issue. Include affected commit, kernel/config if relevant, minimal reproduction, impact, and recovery observations. Remove secrets and unrelated personal data. Do not post a weaponized reproduction in a public issue before coordinated review.
The sole current maintainer is Denny-Lin. There is no guaranteed response SLA; a target of seven calendar days for initial acknowledgement is an aspiration. If private reporting is unavailable, consult the maintainer's profile for a private contact route and avoid posting sensitive details publicly.
Review denial of service from unfair scheduling, map growth, overflow, verifier mistakes, untrusted task behavior, model poisoning, privileged-loader inputs, and telemetry leakage. The model must never bypass CPU affinity or kernel scheduling-class constraints. Watchdog fallback addresses some scheduler failures, not all performance or isolation failures.
The loader defaults to an unlimited lifetime and owns an unpinned struct_ops link. Explicit finite trials remain available. The opt-in systemd unit uses readiness notification after confirmed registration and an initial health check, with Restart=no: a scheduler fallback or failure must not cause a restart storm. The deployment helper never invokes a global SysRq abort or stops a competing scheduler. A deliberate stalled-task test requires a finite duration, explicit fault flags, partial switching, an exact target TGID and a detected QEMU/KVM VM; it is unavailable through the friendly helper. Watchdog and loader-death recovery passed on the recorded kernel; this does not guarantee recovery from arbitrary kernel failures or validate long-term behavior.
The raw loader defaults to learning task names beginning with lertick, or an explicit TGID. The native helper and service explicitly enable --track-all for ordinary applications. Tracking controls learning eligibility, not which eligible fair-class tasks sched_ext schedules. Continuous runs default to low-frequency aggregate summaries without per-task identifiers. Explicit finite raw-loader runs retain full research snapshots; --full-stats opts into them for continuous runs. Full snapshots retain task names and numeric PIDs, but no command-line contents. Kernel failure dumps and journal metadata may contain additional identifying information. Review task churn, hostile workloads, fairness, and model poisoning before broader deployment.
Requested telemetry files are newly created with mode 0600; existing files and special paths are refused. The retained snapshot map holds at most 4,096 entries; map-full failures are counted. Live per-task BPF storage follows kernel task lifetime. Compact output does not remove the internal per-task state needed for scheduling. Journald retention follows host policy, and explicit standalone telemetry files have no automatic rotation.
lertick report produces a local report and never uploads it. The default excludes raw journal and task details; --include-logs explicitly includes bounded raw diagnostics that may contain personal data. It runs with the caller's permissions and records missing optional data when access is denied. Inspect every report before sharing it. See report privacy.
Build from a checkout that other users cannot modify, and use a protected root-owned installation prefix. Builds and dependency downloads run as the normal user; only installation and kernel operations request sudo. A private runtime lock serializes Lertick ownership and maintenance. Uninstall disables/stops the owned managed service, but refuses to abort a foreign or independently launched foreground scheduler. Other privileged sched_ext managers do not share the lock, and the kernel remains the final attachment authority. CPU cgroup quotas and hierarchical isolation are not implemented or validated by this scheduler; do not assume those policies retain their fair-scheduler semantics during a trial.
Managed updates fetch/build the candidate as the normal user, stage an exact protected bundle and verify it before stopping the owned service. Promotion and rollback cover the loader, helper, management files and unit together. Startup failure can trigger one restoration attempt; repeated failures leave default Linux scheduling available instead of retrying indefinitely. Updating trusts the selected upstream source and toolchain; it is not a signature-verification or software-supply-chain guarantee. A lifecycle test does not establish that the candidate improves throughput, latency or isolation.