Repository navigation
Systemd boot load shaping #7705
Description
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.serviceunits. 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
Activity
DavidePrincipi commentedon Nov 13, 2025
DO 2vCPUs
Without limit-load generator
With limit-load (2 CPUs, 1 chain)
feat: limit-load Systemd generator (#983)
DavidePrincipi commentedon Nov 14, 2025
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-analyzeshows boot timessystemd-analyze plot > image.svgdumps boot service startup sequences and timesTest case
We expect the boot load peak is lower with the Testing version, whilst the boot duration is longer.
mrmarkuz commentedon Nov 17, 2025
Test case verified
Stable core:
Startup finished in 1.203s (kernel) + 3.315s (initrd) + 12.468s (userspace) = 16.987s
multi-user.target reached after 11.748s in userspace.
Testing core:
Startup finished in 3.059s (kernel) + 5.196s (initrd) + 4min 8.549s (userspace) = 4min 16.804s
multi-user.target reached after 15.178s in userspace.
With the testing version the load during boot was the halved and the server was reachable. As expected the boot time was longer.
DavidePrincipi commentedon Nov 18, 2025
Released