Investigate why `daemon off;` and `master_process off;` are required for nginx to work with the module

[nponsard]

softhsm works perfectly without these options, it looks like a problem with the tokio runtime. I tried the blocking and the non blocking versions, both crashes.

[nponsard]

This seems to confirm my guess : https://github.com/tokio-rs/tokio/issues/4301

Forking when a tokio runtime is runnning is not supported.

[ansiwen]

This seems to confirm my guess : tokio-rs/tokio#4301

Forking when a tokio runtime is runnning is not supported.

That leads to the question: why is the module initialized by nginx before the daemonize fork? Would be better to postpone it. Maybe there is already a possibility in nginx or openssl config to do the module initialization later?

[nponsard]

That leads to the question: why is the module initialized by nginx before the daemonize fork? Would be better to postpone it. Maybe there is already a possibility in nginx or openssl config to do the module initialization later?

It's because Nginx does a test on the configuration before starting, the test includes checking that the private key (on the NetHSM) and the certificate exist and match.

[nponsard]

Look into how openssl is initialized ?

[nponsard]

Check if nginx has an option to "reload" OpenSSL

[nponsard]

maybe an option to not check the configuration when starting ?

[nponsard]

Currently the crash happens when block_on is called on a runtime. This seems to happen when the runtime is shared between PKCS11 function calls. Creating a runtime for every function call causes some problems with the HTTP connection pool not being shared.

[nponsard]

It's super weird because the block_on function works perfectly for the same PID when the functions C_FindObjectsInit and C_SignInit are called. It "hangs" always in C_Sign

[nponsard]

The difference is that both functions that work only do a lock on the internal DB whereas C_Sign does an HTTP request

[nponsard]

fixed by #103