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