Thanks. Possibly related, with explanation ahead:
I'm still debugging the service layout I have. /var/chroot/gnunet is the $HOME of the 'gnunet' system user (which runs the system service). system user logs go into /var/chroot/gnunet/cache, hostlist, topology into /var/chroot/gnunet/.config, and all the rest into /var/chroot/gnunet/data. The service I start for my user (and the user services) has no read access to this directory. What problems could cause that? Should I solve this differently, or is a change like a gnunet:gnunetdns as owner for /var/chroot/gnunet and adding my user to gnunetdns enough (or no changes and just adding to gnunet group) enough? $/HOME/.cache/gnunet/gnunet-2022-04-11.log 2022-04-11T08:17:11.373925+0200 namestore-656 ERROR Assertion failed at sq_result_helper.c:180. 2022-04-11T08:17:11.374183+0200 namestore-656 ERROR Assertion failed at plugin_namestore_sqlite.c:537. 2022-04-11T08:17:11.374232+0200 namestore-656 ERROR Assertion failed at gnunet-service-namestore.c:1949. looks like there is some issue related to accessing information? Schanzenbach, Martin transcribed 1.9K bytes: > Hi, > > this is not a known bug and it would be very odd if the REST API is not even > used. > > So yes, debug logs would be helpful. > > BR > > > On 10. Apr 2022, at 22:31, Nikita Ronja Gillmann <gnu...@klang.is> wrote: > > > > Hi, > > > > in my system service I have a pill + kill for gnunet-rest-server, > > as this process seems to not react to gnunet-arm -e. > > > > I am not sure how to debug this. look at loglevel DEBUG logs? > > It seems like a bug to me when this prevents a normal shutdown > > of gnunet. > > > > This is via the user process, not the system process run as the > > system user "gnunet". > > > > Any clues before I sent in logs? Is this is a known bug? > > >
