Re: gnunet-rest-server shutdown issues

[Nikita Ronja Gillmann]

Nikita Ronja Gillmann transcribed 3.1K bytes:
> 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 <gnunet@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 <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?
> > >>>> 
> > >>> 
> > >> 
> > >> 
> > >> 
> > > 
> > 
> 
> 
>

rest-server.pkill.log
Description: Text document