I’m trying to run a service written in Common Lisp using systemd, but I’m stuck on the dependencies.
I’ve been able to get a service up and running before, by just launching SBCL and running quicklisp to load all dependencies. I wanted to do it correctly and reproducably this time, using the packages available from pkgs.lispPackages (and packages that I added myself using buildLispPackage). That works, everything builds…but now I can’t figure out how to run it. The dependencies are available when building the packages, but when I try launching it via systemd, none of the dependencies are found.
I’ve tried making an executable image (via save-lisp-and-die), but when I try running the resulting executable, I get an error saying it’s corrupted.
I’ve tried launching the script in the systemd definition via ${lispPackages.clwrapper}/bin/common-lisp.sh, but it doesn’t see the dependencies. I tried wrapping the common-lisp.sh call in a derivation with appropriate dependencies, but that didn’t work either.
Am I missing something obvious? Is there a ‘correct’ way to run the clwrapper scripts such that they correctly find dependencies? Or will I just have to manually add all direct and inherited dependencies in systemd.services..environment.CL_SOURCE_REGISTRY?
Are there any examples of services that use Common Lisp for use as a reference?
I’m trying to run a service written in Common Lisp using systemd, but I’m stuck on the dependencies.
(Note that as I do not use mainline NixOS or Common Lisp on systemd-based systems, I have nto tested any of that with systemd, I just assume «freshly created user and not internet access» is close enough)
I’ve tried making an executable image (via save-lisp-and-die), but when I try running the resulting executable, I get an error saying it’s corrupted.
Corrupted is strange… There are some weird fixes for the case of shared library; see lispPackages.stumpwm that builds an executable that seems runnable.
I’ve tried launching the script in the systemd definition via ${lispPackages.clwrapper}/bin/common-lisp.sh, but it doesn’t see the dependencies. I tried wrapping the common-lisp.sh call in a derivation with appropriate dependencies, but that didn’t work either.
For script-like launching, I would start with something in the vein of (tested in a no-net empty-home sandbox):
Am I missing something obvious? Is there a ‘correct’ way to run the clwrapper scripts such that they correctly find dependencies? Or will I just have to manually add all direct and inherited dependencies in systemd.services..environment.CL_SOURCE_REGISTRY?
I admit that Lisp packaging has never reached the level of «correct», but hopefully we are at «working».
BTW, I remember someone started something for bundling Quicklisp-downloaded packages behind a single fixed-output (like Nixpkgs Cargo handling etc. works). Never used it though.
Corrupted is strange… There are some weird fixes for the case of shared library
I bet that’s it! In order to get access to newly-added packages, I was using the unstable channel for Lisp packages. I bet there was some linking against ‘future’ SSL libs.
I wonder if it’d work if I manually package what I want (namely, cl-postgres & postmodern). I did already add some myself.
I don’t really understand your alexandria example…doesn’t that just make the one package available?
I did eventually get it working, by manually adding all packages to CL_SOURCE_REGISTRY one at a time. There were something like 30-40 Lisp dependencies in total. Not exactly ideal, since my server will break if any of my deps add a new dep…
I bet that’s it! In order to get access to newly-added packages, I was using the unstable channel for Lisp packages. I bet there was some linking against ‘future’ SSL libs.
Wait, you use unstable-built core with stable SBCL? OK, that is not supposed to work, cores are very SBCL-build specific (upstream position is that a core is for exact same SBCL that was used to compile it)
I don’t really understand your alexandria example…doesn’t that just make the one package available?
It would add all the dependencies if there are any, and you can use buildLispPackage for your own package that has not code only depedencies. Or indeed your server code.