Upstream `systemd-socket-proxyd` module to NixOS

[axelkar]

That looks super useful. Could it be upstreamed to NixOS?

[sodiboo]

I agree! It does look super useful! I have even intentionally written it in a Nixpkgs idomatic style, with the intent to upstream it at some point.

Given that it inherently needs to be multi-instanceable to be useful, i think it is a perfect candidate for the "modular services" that have recently been introduced to Nixpkgs. That is, stuff under system.services. Then, it can also be neatly bundled with any other modular services! How nice! However, for this to be ergonomic, i really think that i ought to be something like config.socket.name in the service. That way, i can map this stuff, or that stuff to modular services.

I'd want the service dependencies to maybe look like this?

# user code, roughly
{config, ...}:
{
  # let's say we have some socket-activated-ish continuwuity
  process.argv = [ "continuwuity" ... ];
  systemd.service = ... ;

  # so we import my module
  imports = [ socket-proxy-module ];
  # we configure the upstream
  continuwuity.settings.listen-socket = "@continuwity-backend";
  socket-proxy.upstream = "@continuwuity-backend";

  # and then just configure sockets i suppose?
  systemd.socket = {
    requiredBy = [ "caddy.service" ];
    listenStreams = [ "@continuwuity" ];
  };
}

# socket proxy module
{config, ...}:
{
  systemd.services.socket-proxy = {
    requires = map (socket: socket.name) (builtins.attrValues config.systemd.sockets);
    bindsTo = [ config.systemd.service.name ];
    after = [ config.systemd.service.name ];

    # probably an ExecStart in here but like. this is just to show the unit dependencies
  };
}

but that config.systemd.sockets.*.name and config.systemd.service.name and such? can't exist in the current form of modular services. those are deferred modules so i cannot read the name of the service it generates. and because such a service may be arbitrarily nested with an unknown prefix, i also cannot guess the names.

and it was upon this realization that i stopped dedicating more time to it for now. because it works on my machine for my needs.

yeah the module could be merged as-is, but i think it fits very well into the modular services keyhole (because intended use will always have it as part of another "logical" service on the system, after all), and as such i do want to convert it to a modular service before upstreaming. but to convert to a modular service, i need to fix this annoyance/limitation. as far as i can tell, this limitation was not a problem yet because there are like two(?) modular services In Total and neither of them use more than one systemd unit. so uh. yeah. i'm pretty sure it's not intentional that i can't declare unit dependencies.

[axelkar]

I was actually thinking about modular services when writing this issue. I had no idea more than one systemd service could be defined. And about the deferred module, I have no idea why it's like that so I'll ping @roberth for potential solutions

Edit: Quick Google search later: I'm guessing it's something to do with the modular services submodule containing an alias to systemd.services. Can the system systemd.services be made influence the modular service config.systemd.services? Why isn't it possible with a regular submodule?

[axelkar]

I guess this could be implemented by providing a NixOS module that defines options in the modular services namespace, and implements everything outside it. That removes the possibility of overriding this module's implementation from inside the modular service, but 🤷‍♂️. Or maybe the systemd dependency thing could have a little NixOS stub to piece things together?