kubo: default installation gives null API field instead of some unix domain socket

[Jorropo]

Describe the bug

We got theses reports of Kubo panicing on startup due to probably an empty API field ipfs/kubo#10056. This is a bug in our software however I belive this is also a bug in:

nixpkgs/nixos/modules/services/network-filesystems/kubo.nix

Line 186 in cf73a86

default = [ ];

Because a Kubo daemon without an API listener is borderline useless, your choice to change to a unix socket (f2be3ae) makes sense however I think some default got lost and now it is set to Null.

Given I am not a Nix user myself I got help from @justinabrahms to fill in the template, thx ❤️.

Steps To Reproduce

Steps to reproduce the behavior:

1. Add services.kubo.enable = true to /etc/nixos/configuration.nix
2. sudo nixos-rebuild switch
3. systemctl status ipfs notice it's failing with a panic.

Expected behavior

After installation Kubo daemon should start and the RPC should be usable by a permissioned user.

Notify maintainers

@Luflosi

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.38, NixOS, 23.05 (Stoat), 23.05.2064.53657afe297`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.3`
 - channels(abrahms): `""`
 - channels(root): `"home-manager-23.05.tar.gz, nixos-23.05"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[Luflosi]

Weird that it works on my machine and in the NixOS tests. One of the NixOS tests only has services.kubo.enable = true; and services.kubo.autoMount = true; options set. autoMount 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 ipfs config show shows that the API field is set to null and yet Kubo starts without a problem and RPC API server listening on /unix/run/ipfs.sock can be seen in the log.
According to a comment at the top of, ipfs-api.socket, "Enabling this [socket file] will completely override any API listeners configured in your config.". NixOS enables this socket file and overrides ListenStream with %t/ipfs.sock (which is /run/ipfs.sock) plus whatever the user has set in services.kubo.settings.Addresses.API. 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 API field to null in the Kubo config doesn't matter because ipfs-api.socket is enabled, which should override this and specify a socket for the API.

[Jorropo]

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 listeners[0] assumption which is panicking since kubo is configured without listeners.

However this is fed by listeners, err := sockets.TakeListeners("io.ipfs.api") which tries to load something like ipfs-api.socket as you linked. So if you have a "API": null but use something like ipfs-api.socket 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 ipfs-api.socket like config is not applied somehow.

[Luflosi]

I was able to reproduce the problem. Maybe I just need to order the ipfs.service unit after the two socket units. I'll take a closer look in the following days when I have some more time.

[ntninja]

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 systemctl status ipfs-api.socket ipfs-gateway.socket and check if both sockets were correctly bound when Kubo crashes in this way.

[Luflosi]

I created #272041, which should fix this.