Thanks, but never mind.
I found the issue. It was not with gnunet.
On Thu, Oct 27, 2022 at 05:35:40AM +, Martin Schanzenbach wrote:
> Do you have code in a repo somewhere that we can try?
>
> On 26.10.22 13:02, accounts-gnu...@holbrook.no wrote:
> > Ok, I understand.
> >
> > Sorry it was no
Do you have code in a repo somewhere that we can try?
On 26.10.22 13:02, accounts-gnu...@holbrook.no wrote:
> Ok, I understand.
>
> Sorry it was not clear:
>
> my main issue was the function registered via
> GNUNET_SCHEDULE_add_shutdown not firing - even if the signal
> handler from gnunet is in
Ok, I understand.
Sorry it was not clear:
my main issue was the function registered via
GNUNET_SCHEDULE_add_shutdown not firing - even if the signal
handler from gnunet is in place.
On Wed, Oct 26, 2022 at 10:22:27AM +0200, Christian Grothoff wrote:
> You should never add your own signal handle
You should never add your own signal handler, GNUNET_PROGRAM_run() does
that already, by adding your own you remove the GNUnet signal handler
and thus break the shutdown logic.
-Christian
On 10/26/22 10:15, accounts-gnu...@holbrook.no wrote:
When running the service with gnunet-arm -i svc, th
When running the service with gnunet-arm -i svc, the function added with
GNUNET_SCHEDULER_add_shutdown is not being run when issuing gnunet-arm -k
svc
If I add a sigterm handler and do GNUNET_SCHEDULER_shutdown there, it
hangs and I have to sigint (and it doesnt halt).
If I run the service direct
