Re: gnunet-rest-server shutdown issues

[Schanzenbach, Martin]

You can try stopping the rest service

$ 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.
If there is not output, I am pretty lost.
Should ctrl-c work, then something odd is going on with the signals from arm?

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

signature.asc
Description: Message signed with OpenPGP