Re: gnunet-rest-server shutdown issues

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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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?
> >>>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >>>> 
> >>> 
> >> 
> > 
> > 
> > 
>