View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009649 | GNUnet | core service | public | 2025-03-22 18:01 | 2025-03-27 09:29 |
| Reporter | noe | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Linux x86_64 | OS | Guix | ||
| Product Version | 0.23.0 | ||||
| Summary | 0009649: gnunet-core does not report errors when connecting to the system daemon | ||||
| Description | In case of missing permissions for accessing /tmp/gnunet-system-runtime/gnunet-service-core.sock the command ”gnunet-core -s” will retry to access the socket forever without producing an error. The only way I found to know the problem was to run strace, which shows a loop of the following output: pselect6(4, [3], [], NULL, {tv_sec=4, tv_nsec=95990000}, NULL) = 0 (Timeout) socket(AF_UNIX, SOCK_STREAM, 0) = 5 fcntl(5, F_GETFD) = 0 fcntl(5, F_SETFD, FD_CLOEXEC) = 0 fcntl(5, F_GETFL) = 0x2 (flags O_RDWR) fcntl(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(5, {sa_family=AF_UNIX, sun_path="/tmp/gnunet-system-runtime//gnunet-service-core.sock"}, 110) = -1 EACCES (Permission non accordée) close(5) = 0 Surely it would be better to stop the loop in case of EACCES and report the error to the user instead? In this case it is the /tmp/gnunet-system-runtime directory that is created but not accessible to the current user that is not in the gnunet group, so there is no hope of getting a connection by just waiting. | ||||
| Steps To Reproduce | Run a multi-user gnunet setup and start a system daemon and a user daemon. For the user, do not have him in the “gnunet” group. gnunet-core -s will wait infinitely instead of reporting the lack of permissions. | ||||
| Tags | No tags attached. | ||||
|
|
Hmm you are right that this behaviour may not be optimal for debuggin purposes. But it is consistent with the connection handle-based API design throughout GNUnet: You usually always get a handle on _connect() to a service, even if the service is not yet running or not taking any connections right now. You can use the handle as normal and command will be buffered until the service becomes available. The alternative would be that you have to handle network/file/misconfiguration-related errors on the client side, in every client. The error or issue should be logged in the logs, so it is not like there is no debugging mechanism at all. |
