#1004589 GNUnet daemon doesn't start successfully

Package:
gnunet
Source:
gnunet
Description:
GNU's framework for secure peer-to-peer networking
Submitter:
Sven Grewe
Date:
2025-11-14 11:21:01 UTC
Severity:
important
#1004589#5
Date:
2022-01-30 19:54:22 UTC
From:
To:
I installed the gnunet package and the GNUnet daemon probably didn't
start successfully. I haven't change any config files.

"# service gnunet status" on a Debian Sid system reports:

●gnunet.service - A framework for secure peer-to-peer networking
     Loaded: loaded (/lib/systemd/system/gnunet.service; enabled; vendor
preset: enabled)
     Active: failed(Result: exit-code) since Sun 2022-01-30 19:54:54
CET; 30min ago
    Process: 448 ExecStart=/usr/bin/gnunet-arm -s -c /etc/gnunet.conf
(code=exited, status=217/USER)
        CPU: 1ms

Jan 30 19:54:54 debian systemd[1]: Starting A framework for secure
peer-to-peer networking...
Jan 30 19:54:54 debian systemd[448]: gnunet.service: Failed to determine
user credentials: No such process
Jan 30 19:54:54 debian systemd[448]: gnunet.service: Failed at step USER
spawning /usr/bin/gnunet-arm: No such process
Jan 30 19:54:54 debian systemd[1]: gnunet.service: Control process
exited, code=exited, status=217/USER
Jan 30 19:54:54 debian systemd[1]: gnunet.service: Failed with result
'exit-code'.
Jan 30 19:54:54 debian systemd[1]: Failed to start A framework for
secure peer-to-peer networking.


I belief that this behavior is not intended.

I first backported the package for myself to my Bullseye system and
tested it there. It probably has similar problems to the original
package from unstable. After that I installed the package on a freshly
installed (Debian 11 without GUI) and upgraded (to Unstable) VM. The
GNUnet daemon seems not to work out of the box there too I guess.

#1004589#10
Date:
2022-07-10 10:21:55 UTC
From:
To:
This bug is not only a problem in version 0.15.3-4, but also in 0.13.1-
2, the version currently in stable, and possibly other versions. I
found a complete solution for 0.13.1-2, and part of a solution for the
version currently in 0.15.3-4.

In the .service-file of the gnunet service (normally
/usr/lib/systemd/system/gnunet.service) variable substitution is used
in the "User="-directive, which is not allowed in systemd
(https://github.com/systemd/systemd/issues/5501#issuecomment-283362610
). If you hardcode the gnunet user in this directive like I did here...

[Unit]
Description=A framework for secure peer-to-peer networking

[Service]
User=gnunet
Type=forking
ExecStart=/usr/bin/gnunet-arm -s -c /etc/gnunet.conf
ExecStop=/usr/bin/gnunet-arm -e -c /etc/gnunet.conf

[Install]
WantedBy=multi-user.target

...the systemd part works fine.

Unfortunately, there is another problem with the underlying gnunet-arm
command, which is used to start the peer. In my version the problem is
that it searches for the binary in the wrong place, which can be fixed
by specifying its location in the gnunet.conf file like this:

[path]
GNUNET_HOME = /var/lib/gnunet/
GNUNET_DATA_HOME = /var/lib/gnunet/data/
GNUNET_RUNTIME_DIR = /var/run/gnunet/

[arm]
START_SYSTEM_SERVICES = YES
START_USER_SERVICES = NO
BINARY = /usr/lib/x86_64-linux-gnu/gnunet/libexec/gnunet-service-arm

In 0.15.3-4, gnunet-arm doesn't find the log file, which is a problem I
wasn't able to find a solution for yet.

I hope that these errors can be fixed as fast as possible, especially
regarding that these seem to be merely configuration issues.

Best regards,
Levin Engel

#1004589#15
Date:
2022-08-04 18:25:54 UTC
From:
To:
Much of this is still a problem in the current version in testing
(0.17.2-1). The paths to the binaries in the gnunet.conf file seems to
have been fixed, but the other two problems remain.

Levin's solution to the user problem (by putting the real username in
the .service file still works, but gnunet still barfs on the logfile
problem. The solution to that is to put the logfile in /var/log/gnunet.
The current version of gnunet creates this directory, with correct
permissions (0755 gnunet:gnunet), but doesn't update /etc/gnunet.conf
to fit. With that file set up like this:

[path]
GNUNET_HOME = /var/lib/gnunet/
GNUNET_DATA_HOME = /var/lib/gnunet/data/
GNUNET_RUNTIME_DIR = /var/run/gnunet/

[arm]
START_SYSTEM_SERVICES = YES
START_USER_SERVICES = NO
OPTIONS = -l /var/log/gnunet/gnunet.log

   gnunet starts up fine.

 .....Ron Murray

#1004589#20
Date:
2022-10-07 16:32:13 UTC
From:
To:
The GNUnet service still doesn't start correctly in version 0.17.6-1.
#1004589#25
Date:
2023-12-17 23:47:09 UTC
From:
To:
Version 0.20.0-3 still fails to start because of the incorrect log path in
/etc/gnunet.conf

By changing it to:

OPTIONS = -l /var/log/gnunet/gnunet.log

I can get the gnunet service to start correctly.

#1004589#32
Date:
2025-11-07 21:47:49 UTC
From:
To:
control: tags 1004589 + pending

Thank you for providing the fix.

Will be submitting the fix in upload to mentors.

Regards,
Syed Shahrukh Hussain.

#1004589#39
Date:
2025-11-14 11:19:29 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
gnunet, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1004589@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Syed Shahrukh Hussain <syed.shahrukh@ossrevival.org> (supplier of updated gnunet package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 7 Nov 2025 12:51:27 +0500
Source: gnunet
Built-For-Profiles: noudeb
Architecture: source
Version: 0.20.0-8
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packages@qa.debian.org>
Changed-By: Syed Shahrukh Hussain <syed.shahrukh@ossrevival.org>
Closes: 1004589 1096741
Changes:
 gnunet (0.20.0-8) unstable; urgency=medium
 .
   * QA upload.
   * Fixed service startup problem (Closes: #1004589).
   * Added patch to fix gcc-15 build failure (Closes: #1096741).
   * Updated Standards-Version from 4.7.0 to 4.7.2.
Checksums-Sha1:
 0c206d342aac8bbe44894ca92e0f8d2cd710dfce 2460 gnunet_0.20.0-8.dsc
 9a288de14b07e819e857ec71b2dea9b5a1e8b6ab 72604 gnunet_0.20.0-8.debian.tar.xz
 0b195549879a101f8c37d6379daade8628d73f3f 16372 gnunet_0.20.0-8_source.buildinfo
Checksums-Sha256:
 53ba7b8e4d23b091fe45c68b1bc1c04f1fc76d772def178e57e51fb822a911b7 2460 gnunet_0.20.0-8.dsc
 9349ed4e387abcdcaf19d9c720eabdc146fc409dd5e78ae64dad863bfeff286f 72604 gnunet_0.20.0-8.debian.tar.xz
 067630c66d75ba96b9c33632f8ed98d30bdeabbdaeed8dda945eda9dbb1da8ed 16372 gnunet_0.20.0-8_source.buildinfo
Files:
 9cd589cafd36839849ef235c224faf86 2460 net optional gnunet_0.20.0-8.dsc
 eabdfc352edb3f2e10ff59374ca3f6c4 72604 net optional gnunet_0.20.0-8.debian.tar.xz
 be024226414357f53ae9682ddc121a5a 16372 net optional gnunet_0.20.0-8_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEd8lhnEnWos3N8v+qQoMEoXSNzHoFAmkXC8MACgkQQoMEoXSN
zHo9Qw/7BFBkcbTt+witqFk51cfhSQ1X5CxxIFPgdf7lEJqePYNXX02n8+/B9C8r
LoevvoO3TccI/55cGDtDuGMN1Yk7JX6wLYVU4XeQRzuzw3H3rRpJRBXid538Rgf4
fiWK83Op1SkKSPoVBRNUX9o5cmjtb+RUTz93q8ER2dgUKjROkU5W94wI0SwwdWFB
2QeZpfhY+gy9haq3ox6H9jx0qblVcVa/RxBZcJU8qU5yWs6eMISj/YkpQcfbedKW
mnw0GQNfr46uRVXlmw2f6G5wsIOdjfvbmGi+hRrUQlxtkuAVD0Fq1qcRL36Y2rsY
Cz8THCt72Dxsk+kK69yqEjRXTQQ5eqB7PT50V0r+hsh9QxGq4+H9+hh3X89r1j5f
IF/9NzKfSreIfS1u0iba/K+7CNf4Wr9ihFJOz5sjFAVf23fesVFOw44HinyDQDLC
YFVUoHotqJ+seRo7zI9iFgEAzfLC4q5tP3q4k24kh8JsSRgHSVqW4MuO79XavG85
8DEluxx9BDm0A79yRF9ok4QDgk1YqykZp4VmyZDovRPXpQ9rDeDHGnotuAm1c9NF
PYKyWW0TcWcLK/a66ynjf6a2S9jQEGnqcxaeGrOsSVcf9WjaHdmghYYGslXiBc38
KvFn0Vgsat+z3yznfI/Xw0/hwiuT1BmDTuAuZ6F2Z49TMZznULU=
=z3gU
-----END PGP SIGNATURE-----