Modular services meeting #4 2026-07-10

Development
1

Attendees: @eveeifyeve @roberth, @artemist, @kiara, @aanderse

  • @eveeifyeve: Should we create a team?

  • @roberth: Yes, and I can do it. But we need a name.

    • @roberth: Not sure if package modules is exactly the right name. We have three concepts that are quite distinct, and two give rise to the name “package module”
      • derivation
      • package (attrset)
      • package runtime configuration
    • @roberth: Maybe the formal name should be “package usage module” or “package runtime module”, but then informally we’d still call them package modules
    • @roberth: Or should we rename them to “runtime modules” - short, distinct and meaningful
    • @eveeifyeve: I am not really sure about the naming probably best to ask in a future meeting.
    • @roberth: agreed

  • @eveeifyeve: It would be good to have a followup review from @aanderse to do the following touches as I have responded to previous review.

    • @roberth: Would be good to make the meaning of the null values completely explicit. Kind of like Hyrum’s law, every detail will be depended on, so we should avoid any ambiguities about it.
    • @roberth: My guess for reloadSignal would be that null means never send a signal. Otherwise that’s not representable. Leaving the choice of signal to the service manager would be a bit chaotic. Would be good to have @aaronanderse input on this.
    • @roberth: For reloadCommand, similar. If both are unset, the service does not support reloading. Should a service manager fall back to restarts or just leave the old service running? This should become an option. Could postpone - not in this PR.
    • @eveeifyeve: Agreed, It would be great to have @aaronanderse input, as I am not sure.

  • @eveeifyeve: Progress on the process.environment pr, as it would be useful for the database modular services flake I am creating.

  • @eveeifyeve: Would it be good to have a wrapper function for making search.nixos.org backend responsible for combining the NixOS and service option that wraps the ability to define the modular services, disable the docs and options?

  • @eveeifyeve: Wondering how the progress on adding Modular Services to nixbsd, as I have made a review regarding testing as there was a merged pr regarding testing modular services and I was wondering if there is more help needed.

    • @roberth: I noticed NixBSD switched their class to nixos, which is interesting. Not what I imagine, but if they can pull off decent NixOS option compatibility, that’s great!
    • @artemist joins (by great coincidence)
    • @artemist: …
    • @artemist: What would be possible to move in tree into nixpkgs?
      • @artemist: e.g. could we put a core freebsd service configuration in pkgs/os-specific/bsd
        • Would still rely on option definitions in external repo
      • @artemist: Modular services helps add new content to NixBSD, but was never designed to ease the maintinence burden
      • @artemist: a “Maximum Modular Services” would involve splitting services into a modular part and a non-modular part, e.g. sshd service and config in modular services, pam outside.
      • @artemist: I think the biggest issue is the modules in nixpkgs.
      • @robeth: We already have some nixos extentions already, e.g. you can query options?systemd and then let your module do more.
      • @artemist: The problem would be the hack usage of tmpfiles.
      • @roberth: tmpfiles usage in NixOS is a bit weird. I feel like we could do better
    • @artemist: NixBSD could implement VM tests for testers.modularServiceCompliance
    • @eveeifyeve: Could be nice to have Darwin VMs in the future, but would be unfree
      • @artemist: Only 2 VMs at a time limit. Windows has no limit for 11 Pro and higher-end Server
    • @eveeifyeve: Many proejcts have separate module systems (e.g. NixOS, NixBSD, new nix-windows which I am working on), keeping compatibility is challenging
      • @artemist: NixBSD borrows modules directly from NixOS, but that creates its own challenges
    • @artemist: The Maximum Modular Services idea would be interesting to try out
    • Some discussion about config portability
      • @roberth: Translating upstream systemd units is not entirely impossible, but would be complex. I think our current course for portability is good
    • @artemist left
    • @KiaraGrouwstra joins
    • @KiaraGrouwstra: I have architectural concerns about notificationProtocol, as it has details for arbitrary service managers whereas lib should be agnostic
    • @roberth: Could use extensible enum pattern
    • @eveeifyeve: It should be a list
    • @roberth: It’s needed by the systemd logic because systemd needs to know whether to expect a response from the service.
    • @roberth: Backtracking on extensible enum because it makes service definitions unnecessarily hard because it would have to add conditionals not to “offend” the service manager with unknown values.
    • We reached the decision to allow this enum, which models a service property that’s largely independent of service manager implementation. (Protocols are a “small waist” even if it’s multiple ones)
    • *@aanderse joined
    • we caught up on the reloading PR, which is close to done

  • Followup:

5 Likes
2

I like the split modular and global because it makes the usage of global resources very explicit. Even if there is no need to run multiple sshd instances, I think it’s elegant that we make it possible to do so (I.e. the modular part).

1 Like