I’m currently working on a custom NixOS module to manage service dependencies; but I’m running into some issues where the services aren’t starting in the correct order. I’ve defined a module that ensures a service starts only after its dependent service is running; but the dependencies don’t seem to be respected during boot, and the services are being started simultaneously instead.
I’ve tried using systemd unit dependencies (e.g., After=, Requires=), but the behavior is inconsistent.
The services seem to be starting too early, ignoring the after directive. I’ve checked the journal logs and see no indication of errors, but the services are not following the intended startup sequence. Checked NixOS ManualMinitab documentation guide but still need advice .
Has anyone faced similar issues while defining custom service dependencies in NixOS, and is there a recommended approach to enforce the correct order of startup for dependent services?
Make sure the serviceConfig.Type for each of these is correct. It determines exactly when systemd considers a unit “up”.
If systemd considers them running too early it’ll seem as if the after isn’t being respected, but in reality systemd just schedules the next service immediately after forking the first, which may not be soon enough to bring up whatever they actually provide. In some cases, you may need to implement the notify protocol so that you can signal to systemd when startup has actually finished, othertimes you may need systemd socket or file units.
Making your architecture robust to services starting out-of-order is also usually sensible, and may be more doable than it seems at first.
You’re looking for requires instead of after. From what I understand, after is for ordering unit startup and requires is for dependency. And your post suggests that you want dependency.
Note that those settings are independent of and orthogonal to the requirement dependencies as configured by Requires=, Wants=, Requisite=, or BindsTo=. It is a common pattern to include a unit name in both the After= and Wants= options, in which case the unit listed will be started before the unit that is configured with these options.
Sorry, I’d completely missed that there was no Requires= set. If the units have no other dependencies I’d still expect them to be ordered correctly, though, since they should all only be WantedBy=multi-user.target, so there will likely still be some issue with the Type= settings in addition to missing Requires=.