lightningd creates 4000 child processes on startup about lightning

[rustyrussell]

Thomas Daede [email protected] writes:

These seem to be created sequentially and so are harmless, other than slowing down startup and being annoying in gdb.

That's probably the block scanning.

We should save and restore the topology in the database, and load it
directly instead (we only need block headers, and the few transactions
we're actually watching).

This would also solve the problem of old nodes beinv very slow to
restart.

Thanks!
Rusty.

lightningd(27832): ID: xxx
Detaching after fork from child process 27836.
Detaching after fork from child process 27837.
Detaching after fork from child process 27838.
Detaching after fork from child process 27839.
...
Detaching after fork from child process 31926.
Detaching after fork from child process 31927.
Detaching after fork from child process 31928.
lightningd(27832): No fee estimate: using default fee rate
lightningd(27832): No fee estimate: using default fee rate
Detaching after fork from child process 31929.
lightningd(27832): Creating IPv6 listener on port 38377
lightningd(27832): Failed to bind on 2 socket: Address already in use
Detaching after fork from child process 31930.
lightningd(27832): Hello world!

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#49

[cdecker]

Won't get rid of the block scanning for blocks in between shutdown and startup, but that's not going to be as many anymore.