gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnunet-rest-server shutdown issues


From: Nikita Ronja Gillmann
Subject: Re: gnunet-rest-server shutdown issues
Date: Mon, 11 Apr 2022 13:46:01 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]