Systemd boot load shaping

[DavidePrincipi]

Introduce a systemd generator that dynamically creates dependency and rate-limiting logic for lingered application sessions user@UID.service at boot.

Ensure applications (which run as lingered users) start in controlled tiers rather than all at once.

This feature aims to smooth system load during cluster boot, preventing CPU and I/O congestion from simultaneous application startups while keeping the process deterministic and fully integrated with systemd.

Proposed solution

• Provide a configuration file /etc/linger-shaper.tiers to map applications to their tier, with unlisted apps defaulting to tier-2.
• Implement the boot logic entirely through systemd drop-ins and helper units, without long-running daemons.
• Allow future extension for tier auto-assignment from NS8 application metadata.

Support three priority levels:

• core apps — start first, sequentially.
• tier-1 apps — start next, in parallel but limited to nproc/2 concurrent sessions.
• tier-2 apps — start last, with the same parallel limit.

Alternative solution

• Generate Systemd drop-ins for user@UID.service units. Add After= dependency to shape the load.
• After= Dependency is generated to start at most nproc/2 chain of units at the same time.
• Make user@ unit startup blocking, until the user session is fully up.

Additional context

Boot time load recorded by netdata:

See also

• Many support requests on community.nethserver.org where Samba AD fails to start for service unit timeout.
• Discussion https://mattermost.nethesis.it/nethesis/pl/hecj9e9p53gw8jzy8h71j59uhw

[DavidePrincipi]

DO 2vCPUs

Without limit-load generator

With limit-load (2 CPUs, 1 chain)

[DavidePrincipi]

In Testing Core 3.14.0-dev.3

Run the test on a NS8 leader node hosting many applications and multiple user domain providers. I suggest installing also Netdata to collect high-resolution load and compare the boot-time load with and without the new feature.

At the end of system boot use the following commands to collect additional information:

• systemd-analyze shows boot times
• systemd-analyze plot > image.svg dumps boot service startup sequences and times

Test case

• With core stable, reboot the node and collect baseline metrics
• Update to core to Testing version
• Reboot the node and check how metrics differ

We expect the boot load peak is lower with the Testing version, whilst the boot duration is longer.