Re: gnunet-rest-server shutdown issues

[Nikita Ronja Gillmann]

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 <gnunet@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?
> > 
>