The hang produces no DEBUG infos, all I get for that (when stopping the user service) is, in addition to what I posted:
2022-04-11T09:04:32.426431+0200 arm-2811 WARNING Service `rest' terminated with status signal/9, will restart in 1 ms which is expected as I kill with -9. Nikita Ronja Gillmann transcribed 1.8K bytes: > 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? > > > > > > > >