Hi, so the issue still exists, but I didn't have the time to send more information, busy last months. I'll try to get back to you soon.
As an aside: I haven't followed gnunet development that much recently, but as I have started to add invocations for a couple of BSDs to gnunet-dns-helper (a long time ago and ran out of time as well), I was wondering if those firewall parts would eventually become obsolete in the rewrites you are doing right now, long-term? Schanzenbach, Martin transcribed 5.0K bytes: > Did the output "Shutting down..." appear before or after the normal > shutdown trigger (ctrl-c or gnunet-arm -e)? > If it appeared with the normal shutdown, then I really don't know. > According to the pkill log there is another select happening before the > SIGKILL, > but I cannot see where this is coming from. The cleanup logic looks ok. > > If the log message appears after the SIGKILL then I need to investigate a bit > further, > but it may be a signal handler issue. > > BR > > > On 11. Apr 2022, at 13:46, Nikita Ronja Gillmann <gnu...@klang.is> wrote: > > > > Hi, > > > > Schanzenbach, Martin transcribed 4.0K bytes: > >> You can try stopping the rest service > >> > >> $ gnunet-arm -k rest > > > > here it continued running, for whatever reason. > > No return from gnunet-arm -k rest. > > > >> > >> and then starting it manually through the server binary. > >> Then try to ctrl-c it. > >> > >> If that also does not work, maybe look at the output there. > > > > the output did not provide any useful insights. > > I did a couple of runs, but in both I had to pkill rest-server. > > > >> If there is not output, I am pretty lost. > >> Should ctrl-c work, then something odd is going on with the signals from > >> arm? > > > > CTRL-C didn't work. > > Would the two kdump logs I did for this help? > > > >> > >> BR > >> > >>> On 11. Apr 2022, at 09:06, Nikita Ronja Gillmann <gnu...@klang.is> wrote: > >>> > >>> 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? > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >> > > > > > > >