Re: gnunet-rest-server shutdown issues
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 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 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 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
Re: gnunet-rest-server shutdown issues
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 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 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? > > >>> > >> > >> > >> > > >
Re: gnunet-rest-server shutdown issues
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 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 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
Re: GNUnet Name System not working (as expected)
> On 11. Apr 2022, at 09:13, Tanguy LE CARROUR wrote: > > Hi Martin, > > > Quoting Schanzenbach, Martin (2022-04-09 10:27:56) >>> On 8. Apr 2022, at 16:02, Tanguy LE CARROUR wrote: >>> Quoting Nikita Ronja Gillmann (2022-04-08 12:29:43) Tanguy LE CARROUR transcribed 6.2K bytes: > […] > 2022-04-07T17:14:01.005084+0200 nat-29505 ERROR UPnP enabled in > configuration, but UPnP client `upnpc` command not found, disabling UPnP I assume that you have upnpc(-mini?) as dependency in the guix package. When you look at the C code in src/nat/ you'll see 2 files which you need to patch for them to work for Guix (same applies for the cases where iptables, ip6tables, and ip binaries are used). >>> >>> Correct. `miniupnpc` is an `input`, not a `propagated-input`, >>> so I will have to patch the files using it. Thanks for pointing out! >>> >>> I'll submit a patch for the package definition. >>> >>> In the meantime, I installed `miniupnpc` to make it available for `gnunet` >>> to use… unfortunately, I now have the following warning: >>> >>> ``` >>> 2022-04-08T15:50:35.608148+0200 nat-16852 WARNING upnpc failed to create >>> port mapping >>> 2022-04-08T15:50:35.608229+0200 nat-16852 WARNING upnpc failed to create >>> port mapping >>> ``` >>> >>> But, I guess, WARNING is better than ERROR! :-) >> >> upnp only works if your router supports it and it is enabled on the router. >> (you often get a big warning when enabling it on the router) > > Correct (again)! I activated UPNP on my box and the error disappeared. > But, I cannot do the same on my other computer because I have no control > over the "box" and cannot forward ports! > > Does this mean that I cannot use GNUnet on this computer?! It just means that NAT will not work. So, you will be able to connect to other peers, but other peers will not be able to initiate a connection to your peer. There are other methods to do NAT apart from upnp including a manual configuration. This will improve in the next iteration of NAT and TNG. > > This gets me back to the question: would it be possible to provide a > public test zone for people testing GNUnet with only one computer?! > > Regards, > > -- > Tanguy signature.asc Description: Message signed with OpenPGP
Re: GNUnet Name System not working (as expected)
Tanguy LE CARROUR schreef op ma 11-04-2022 om 09:13 [+0200]: > Correct (again)! I activated UPNP on my box and the error disappeared. > But, I cannot do the same on my other computer because I have no control > over the "box" and cannot forward ports! > > Does this mean that I cannot use GNUnet on this computer?! IIRC there is also a TCP transport that can function without port forwarding (at least, if a sufficient amount of peers have the TCP transport with a public port). Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Re: GNUnet Name System not working (as expected)
Hi Martin, Quoting Schanzenbach, Martin (2022-04-09 10:29:09) > > On 8. Apr 2022, at 16:02, Tanguy LE CARROUR wrote: > > Quoting Nikita Ronja Gillmann (2022-04-08 12:29:43) > >> Tanguy LE CARROUR transcribed 6.2K bytes: > >>> I'm not reporting this into the bug tracker (yet), because (good) chances > >>> are the problem exists between the chair and keyboard… > >>> > >>> ``` > >>> 2022-04-07T17:14:00.996911+0200 peerstore-sqlite-29500 ERROR Error > >>> executing SQL query: attempt to write a readonly database > >>> PRAGMA auto_vacuum=INCREMENTAL > >>> 2022-04-07T17:14:00.997101+0200 peerstore-sqlite-29500 ERROR > >>> `sqlite3_step' failed at plugin_peerstore_sqlite.c:211 with error: > >>> attempt to write a readonly database > >> > >> Where is the $HOME of the gnunet user? Is it writeable for you? > > > > *ERF* the `sqlite.db` belonged to another user and was created… back > > in 2020!? O_o' > > Yes. It is also my impression from the logs that the sqlite database is a > problem. > It seems to be readonly for whatever reason. Try deleting it? Correct! I removed it when I figured out it belonged to another user and the error went away. -- Tanguy
Re: GNUnet Name System not working (as expected)
Hi Martin, Quoting Schanzenbach, Martin (2022-04-09 10:27:56) > > On 8. Apr 2022, at 16:02, Tanguy LE CARROUR wrote: > > Quoting Nikita Ronja Gillmann (2022-04-08 12:29:43) > >> Tanguy LE CARROUR transcribed 6.2K bytes: > >>> […] > >>> 2022-04-07T17:14:01.005084+0200 nat-29505 ERROR UPnP enabled in > >>> configuration, but UPnP client `upnpc` command not found, disabling UPnP > >> > >> I assume that you have upnpc(-mini?) as dependency in the guix package. > >> When you look at the C code in src/nat/ you'll see 2 files which you > >> need to patch for them to work for Guix (same applies for the cases > >> where iptables, ip6tables, and ip binaries are used). > > > > Correct. `miniupnpc` is an `input`, not a `propagated-input`, > > so I will have to patch the files using it. Thanks for pointing out! > > > > I'll submit a patch for the package definition. > > > > In the meantime, I installed `miniupnpc` to make it available for `gnunet` > > to use… unfortunately, I now have the following warning: > > > > ``` > > 2022-04-08T15:50:35.608148+0200 nat-16852 WARNING upnpc failed to create > > port mapping > > 2022-04-08T15:50:35.608229+0200 nat-16852 WARNING upnpc failed to create > > port mapping > > ``` > > > > But, I guess, WARNING is better than ERROR! :-) > > upnp only works if your router supports it and it is enabled on the router. > (you often get a big warning when enabling it on the router) Correct (again)! I activated UPNP on my box and the error disappeared. But, I cannot do the same on my other computer because I have no control over the "box" and cannot forward ports! Does this mean that I cannot use GNUnet on this computer?! This gets me back to the question: would it be possible to provide a public test zone for people testing GNUnet with only one computer?! Regards, -- Tanguy
Re: gnunet-rest-server shutdown issues
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 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? > > > > > > > >
Re: gnunet-rest-server shutdown issues
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 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? > > >
