Engine lifecycle and fork

[Ramkumar Balu <rbalu@xxxxxxxxxxx>]

Kindly explain the expected behavior from an engine when the application forks.

In case of an engine that uses system-wide resources and cannot work properly when duplicated (forked), is it possible to enforce/hint the application in any way to follow init-after-fork? Is there any guidelines for applications to perform fork and engine init in certain order?

 

Difference in behavior of OpenSSL speed -multi application:

1. When using command line option to set engine, the speed application explicitly delays engine init until fork happens. The speed application doesn’t call Engine_init() while parsing command line arguments. Below comment can be seen in code,

  /*

     * In a forked execution, an engine might need to be

     * initialised by each child process, not by the parent.

     * So store the name here and run setup_engine() later on.

     */

 

From this, can it be inferred that OpenSSL doesn’t expect an engine to work across forks?

 

2. When using conf file to load engine, unlike above scenario, the engine is initialized in parent process while parsing conf file itself. OpenSSL doesn’t seem to give the application control over initialization of engine specified in conf file. Thus, while using speed -multi with conf file, the engine is not initialized in the child processes but only in parent.

 

Considering an engine that cannot work across forks, what should be the way to go?

 

Thanks,

Ramkumar Balu