looking through some module definitions, I came across only custom definitions of services and never saw the .service file shipped with the package being reused (Example). when creating my own module, I don’t want to waste time porting the shipped .service file to the nix syntax, and I don’t want to waste time supporting this module even more. is there a way to specify the content or path to the .service file ?
There’s nothing to stop you from exposing a systemd service file to the daemon. The right combination of existing options maybe using environment.etc or tmpfilesd.
If you’re contributing this module to nixpkgs I think you will be required to port it to nix syntax.
A lot of nixos modules reuse the units from a derivation. You can grep nixpkgs for systemd.packages for examples.
2 Likes
This would not be the right approach. As @adamcstephens said, the systemd.packages option is where to look. Something like systemd.packages = [pkgs.foo]; will cause the systemd unit files to be pulled out of the foo package output and linked into /etc/systemd/.
1 Like
thank you for pointing out to this option, but could you explain this particular example with Syncthing ? if systemd.packages is used (here), then why, apparently, should the same systemd module be declared using nix syntax a few lines below?
Those are actually different units. The syncthing derivation provides a user service as well as a per-user system template service syncthing@.service. The nixos module adds an additional unit syncthing.service with the configuration from the nixos module. I suppose creating a dropin that overrides a single instance of this template service would have been also possible.
Yea that’s actually making an entirely new service unit, separate from the ones included in the syncthing package. The package distributes a system service called syncthing@.service and a user service called syncthing.service. That module is adding another system service called syncthing.service. Since it’s a regular name instead of a template name, and since it’s system instead of user, it’s a different unit altogether. Now why that module creates that service is beyond me, but that’s not the point.