winunitd 0.5.1

winunitd 0.5.1

This patch fixes repeated installation and lifecycle behavior. For Windows
11 Enterprise and Enterprise LTSC x64; no Go or .NET runtime is needed on the
destination.

The MSI is not code-signed yet, so Windows SmartScreen may warn when you open
it. Check the download against this release's SHA256SUMS and build provenance:

Get-FileHash .\winunitd-0.5.1-x64.msi -Algorithm SHA256
gh attestation verify .\winunitd-0.5.1-x64.msi --repo PLN/winunitd `
  --signer-workflow PLN/winunitd/.github/workflows/release.yml `
  --source-ref refs/tags/v0.5.1

Install or upgrade

From an elevated terminal:

msiexec /i .\winunitd-0.5.1-x64.msi /qb

Over 0.5.0 this upgrades in place: the service stops, the new version starts,
and units, enablement, logs and linger grants carry over. See the
installation guide
for installation and earlier package upgrades.

Fixes since 0.5.0

• Repeating installation of the exact installed MSI restores a service that
  was running before the command. A previously stopped service remains stopped
  on a plain repeat install.
• When a process exits and its replacement fails to start, Start and Status
  report failure and the launch error instead of stale active/running status
  with no main process.
• Daemon verification rejects User= in user-manager units, matching reload
  and file verification.
• Daemon shutdown no longer reports a cleanup failure if a child exits between
  the liveness check and termination. Failed termination of a still-running
  child remains visible.

Limits

Support and limitations remain as documented for
0.5.0.
Signing remains deferred.

Qualification

Windows and Linux CI passed on the release source. Before publication, the
actual hosted MSI passed clean installation, same-package installation with
the service initially running and stopped, a cold boot with the enabled worker
returning automatically, and uninstall with retained data. An upgrade from the
public 0.5.0 MSI preserved the worker unit files and enablement, returned the
service and worker, and left only the new product registration; uninstall
passed afterward. Checksums, the clean package manifest and both hosted build
attestations were verified against the exact release tag.

winunitd 0.5.0

winunitd 0.5.0

System units can now run as an ordinary account: User= names the account,
and winunitd logs it on without a password. For Windows 11 Enterprise and
Enterprise LTSC x64; no Go or .NET runtime is needed on the destination.

The MSI is not code-signed yet, so Windows SmartScreen may warn when you open
it. Check the download instead:

# Compare with SHA256SUMS from this release.
Get-FileHash .\winunitd-0.5.0-x64.msi -Algorithm SHA256
# Confirm that this repository's release workflow built it from the v0.5.0 tag.
gh attestation verify .\winunitd-0.5.0-x64.msi --repo PLN/winunitd `
  --signer-workflow PLN/winunitd/.github/workflows/release.yml `
  --source-ref refs/tags/v0.5.0

Install or upgrade

From an elevated terminal:

msiexec /i .\winunitd-0.5.0-x64.msi /qb

Over 0.4.0 or 0.3.0 this upgrades in place: the service stops, the new version
starts, and units, enablement, logs and linger grants carry over. A new install
is as described for 0.3.0
and in the installation guide.

New since 0.4.0

• User= on system units. In a FormatVersion=2 system unit of
  Type=simple, oneshot or notify, User= runs the main process, its
  descendants and ExecStop as that account: DOMAIN\name, a local name or a
  SID. No password is involved: before each start the system manager logs the
  account on by S4U, the logon headless linger uses. It loads the account's
  normal profile, creating it on first use, and gives the process the
  account's environment. A start that cannot log the account on fails, and
  Restart= applies. Status shows the account and its SID, and capabilities
  list unit-user-s4u
  (accounts,
  design).

Limits

• A User= unit has no Windows credentials for other machines, and DPAPI,
  Credential Manager and EFS are not available to it. Its logon is a network
  logon: the processes are not in INTERACTIVE, SERVICE or BATCH, and
  taskkill.exe refuses to run; Stop-Process works. An administrator account
  runs with its full, elevated token. LocalService, NetworkService and
  Group= are not supported.
• Otherwise unchanged from 0.3.0:
  Windows 11 Enterprise LTSC build 26100 is the tested platform; Microsoft
  Entra ID accounts are not supported; headless-store-uri,
  RequiresInteractiveSession and Persistent= are experimental; downgrades
  are refused.

Qualification

Hosted CI ran the unit, race and integration tests. Tests that need
LocalSystem and a real account ran on a disposable guest. An MSI with these
changes also ran a User= unit there for an account that never signed in,
covering its stop command, a cold boot, a killed service process, accounts that
cannot log on, and removal
(evidence).
Before publication, this MSI was installed clean, ran a User= unit, and was
installed as an upgrade from 0.4.0 on a disposable guest.

winunitd 0.4.0

winunitd 0.4.0

For programs that supervise their own workers through winunitd: a query that
tells which unit a process belongs to, a public Go client, and a supported way
for SYSTEM or an administrator to run units as an ordinary user without a
sign-in. For Windows 11 Enterprise and Enterprise LTSC x64; no Go or .NET
runtime is needed on the destination.

The MSI is not code-signed yet, so Windows SmartScreen may warn when you open
it. Check the download instead:

# Compare with SHA256SUMS from this release.
Get-FileHash .\winunitd-0.4.0-x64.msi -Algorithm SHA256
# Confirm that this repository's release workflow built it from the v0.4.0 tag.
gh attestation verify .\winunitd-0.4.0-x64.msi --repo PLN/winunitd `
  --signer-workflow PLN/winunitd/.github/workflows/release.yml `
  --source-ref refs/tags/v0.4.0

Install or upgrade

From an elevated terminal:

msiexec /i .\winunitd-0.4.0-x64.msi /qb

Over 0.3.0 this upgrades in place: the service stops, the new version starts,
and units, enablement, logs and linger grants carry over. A new install is as
described for 0.3.0 and in the
installation guide.

New since 0.3.0

• Which unit a process belongs to. winctl unit-of-process PID and the
  unit-of-process control method name the unit whose job holds a process:
  its main process, any descendant, or its stop command. The reply carries the
  invocation, whether the process is the main one, and its creation time, so
  a program that serves a named pipe can attribute a client and rule out a
  reused process ID. Each manager answers for its own units
  (runtime reference).
• Go client. github.com/PLN/winunitd/client dials the system manager or
  any user's manager, checks the identity of the process serving the pipe,
  and offers typed calls with context cancellation. Its types are the control
  protocol's. Until 1.0 its API may change between minor releases.
• Running a user's units from SYSTEM. winctl --user=<user or SID> talks
  to that user's manager, which administrators and LocalSystem may control.
  Status reports each manager's unit directory. The
  procedure covers
  enable-linger, placing the unit file, reload, start and removal.
• Documentation. The runtime reference now says how a lingering user's
  manager takes over from the interactive one at sign-out, restarting enabled
  units once, and what a headless manager's units cannot reach. Statements that
  headless linger was not yet qualified are corrected.

Limits

Unchanged from 0.3.0: Windows 11 Enterprise
LTSC build 26100 is the tested platform; Microsoft Entra ID accounts are not
supported; a lingering user's services have no Windows credentials for other
machines and no DPAPI, Credential Manager or EFS; headless-store-uri,
RequiresInteractiveSession and Persistent= are experimental; downgrades are
refused. System units still run as LocalSystem; User= is planned.

Qualification

Hosted CI ran the unit, race and integration tests for each change. On a
disposable guest, an MSI with these changes ran the whole SYSTEM-to-user
procedure for a user who never signed in, including a cold boot, the Go client
and removal (evidence).
Before publication, this MSI was installed clean and as an upgrade from 0.3.0 on
a disposable guest.

winunitd 0.3.0

winunitd 0.3.0

The first public release of the product MSI, WinUnit Manager, for Windows 11
Enterprise and Enterprise LTSC x64. It replaces the unsigned 0.2.1-beta package.
No Go or .NET runtime is needed on the destination.

The MSI is not code-signed yet, so Windows SmartScreen may warn when you open
it. Check the download instead:

# Compare with SHA256SUMS from this release.
Get-FileHash .\winunitd-0.3.0-x64.msi -Algorithm SHA256
# Confirm that this repository's release workflow built it from the v0.3.0 tag.
gh attestation verify .\winunitd-0.3.0-x64.msi --repo PLN/winunitd `
  --signer-workflow PLN/winunitd/.github/workflows/release.yml `
  --source-ref refs/tags/v0.3.0

Install

From an elevated terminal:

msiexec /i .\winunitd-0.3.0-x64.msi /qb

The package installs the LocalSystem winunitd service, puts winunitd.exe,
winctl.exe and winunit-notify.exe in %ProgramFiles%\winunitd\bin and adds
that folder to PATH (REMOVE=AddToPath opts out). Examples and documentation
are in %ProgramFiles%\winunitd\doc. No workload is enabled. See the
installation guide for repair, upgrade and removal.

From 0.2.1-beta: the MSI refuses to install while the beta is present.
Back up %ProgramData%\winunitd, stop the service, uninstall the beta, then
install 0.3.0. Units, enablement and logs carry over; enabled units start again
(details).

New since 0.2.1-beta

• Installer and servicing. Repair and in-place upgrade stop the service
  cleanly and roll back if the new version fails to start. Data under
  %ProgramData%\winunitd is kept across repair, upgrade and removal. The
  installer refuses conflicting services and unsafe directories, and an
  optional compatibility floor keeps unattended servicing from running an
  unsuitable build. The service writes a daemon log and Windows Application
  log events.
• Units. A cooperative stop command (ExecStop), repeatable oneshots,
  fixed or exponential restart backoff, loopback readiness probes and
  probe-based health checks, BindsTo, and an explicit unit format 2
  (FormatVersion=2) whose policies are listed in the
  unit reference. Timers handle calendar, boot and
  interval triggers across clock changes and DST. Journals stay within bounded
  disk use.
• Control. Start, stop and restart return operation IDs for
  winctl operation, and winctl cancel stops unfinished starts and
  restarts; a maintenance mode quiesces the manager for servicing;
  winctl capabilities reports the running build; status stays available
  under heavy load.
• User managers. Each admitted user gets a manager in their own session
  for their units under %LOCALAPPDATA%\winunitd. winctl enable-linger
  keeps a user's manager running without a sign-in. Both work for local and
  Active Directory domain accounts, including roaming profiles.

Limits

• Tested on Windows 11 Enterprise LTSC build 26100. Other editions, Windows
  Server and ARM64 are not supported yet; see SUPPORT.md.
• Microsoft Entra ID (cloud) accounts are not supported.
• A lingering user's services run without the user's credentials: network
  shares need credentials the service supplies, and DPAPI, Credential Manager
  and EFS are unavailable. While linger holds a roaming profile, the profile
  stops roaming on that machine
  (headless user managers).
• Experimental: the headless-store-uri linger mode,
  RequiresInteractiveSession, and persistent timers (Persistent=).
• Downgrades are refused.

Qualification

Each area was tested on disposable Windows guests. A pilot also ran a real
workload under the installed service, including a 24-hour soak and an upgrade
between two pilot builds. Before publication, this MSI was installed clean and
as an upgrade from the 0.1.1 pilot build on a disposable guest. The
milestones and the evidence documents they link record what
was tested and what was not.

winunitd 0.2.1-beta

winunitd 0.2.1-beta

First installable public-beta candidate for Windows 11 Enterprise/LTSC x64.
Qualified on Enterprise LTSC build 26100.9168. The package is unsigned.

Install the MSI from an elevated terminal. It installs the LocalSystem
winunitd service, three command-line binaries, licenses, unit reference, and
examples. No Go/.NET runtime is required; no sample workload is enabled.

The supported beta path covers simple services and targets, dependency ordering,
logging, configuration reload, explicit enablement, and workload restart policy.
The documented unversioned unit syntax is preserved across beta updates.

Before repair, upgrade, or uninstall, stop the service and wait for Stopped.
The installer enforces this requirement. Back up ProgramData\winunitd and keep
the previous MSI. Uninstall retains configuration and logs. A failed upgrade
requires inspecting the failure and explicitly restarting the restored service.

Stop currently terminates process jobs; graceful application stop hooks are not
implemented. PATH is not changed. Interactive admission defaults to disabled;
user/linger operation and advanced unit types remain experimental. Existing
manual installations require deliberate migration.

The candidate passed install, repair, failed-upgrade rollback, upgrade, reboot,
uninstall/reinstall, and workload recovery on a disposable LTSC guest. Its
binaries also passed an existing Hermes pilot's maintenance rehearsal and
post-recovery conversation check. See qualification
and installation instructions.

Candidate: winunitd-0.2.1-x64-beta.msi (15,888,384 bytes).
SHA256: 8ecabc2e40b03d81a3a683705969dd07b0685bb84ea544e92843d99902d6d141.
Source: 1c56a57ae6001b247c1358a8c7395d734326fe1d.

This is an unsigned prerelease for early adopters; see the qualification and
recovery instructions before using it for important workloads.