Code change:
We got theses reports of Kubo panicing on startup due to probably an empty field This is a bug in our software however I belive this is also a bug in: Because a Kubo daemon without an API listener is borderline useless, your choice to change to a unix socket () makes sense however I think some default got lost and now it is set to . Given I am not a Nix user myself I got help from to fill in the template, thx :heart:. Steps to reproduce the behavior: to notice it's failing with a panic. After installation Kubo daemon should start and the RPC should be usable by a permissioned user. Please run and paste the result.
/cc (I forgot to fill it in the template and I don't belive GH pings peoples from edits)
Weird that it works on my machine and in the NixOS tests. One of the NixOS tests only has and options set. does quite a lot but I didn't see anything obvious why this should affect the API settings. But maybe it does make a difference and maybe I specified some additional option on my machine makes it also work there. I'll try to reproduce it with just the enable option set in the next couple days. On one machine shows that the field is set to and yet Kubo starts without a problem and can be seen in the log. According to a comment at the top of, , "Enabling this [socket file] will completely override any API listeners configured in your config.". NixOS enables this socket file and overrides with (which is ) plus whatever the user has set in . What I don't know is how systemd communicates this information to Kubo but this seems to work. So in conclusion, I would think that setting the field to in the Kubo config doesn't matter because is enabled, which should override this and specify a socket for the API.
Thx I wasn't aware we even had this feature (or that you could use systemd to configure application sockets in the first place). We have a simple incorrect assumption which is panicking since kubo is configured without listeners. However this is fed by which tries to load as you linked. So if you have a but use something like it should work (AFAIT). I can't test experimentally that feeding the API through systemd works right now, I'll report later, but it seems to me that the like config is not applied somehow.
I was able to reproduce the problem. Maybe I just need to order the unit after the two socket units. I'll take a closer look in the following days when I have some more time.
This happened to me too on first installation, the reason was that systemd couldn’t bind port 8080 because it is already in use by another service, then started Kubo anyways. So my theory is that Kubo checks if there was a socket made available by systemd and if there was none falls back to trying to read the listen address from the config (which is then null) and then panics in the observed way. For anyone else affected by this, run and check if both sockets were correctly bound when Kubo crashes in this way.
I created , which should fix this.

Related discussion:
text: Group = cfg.group; StateDirectory = ""; ReadWritePaths = optionals (!cfg.autoMount) [ "" cfg.dataDir ]; <ins> # Make sure the socket units are started before ipfs.service Sockets = [ "ipfs-gateway.socket" "ipfs-api.socket" ]; </ins> } // optionalAttrs (cfg.serviceFdlimit != null) { LimitNOFILE = cfg.serviceFdlimit; }; } // optionalAttrs (!cfg.startWhenNeeded) { wantedBy = [ "default.target" ];