search for: vddk_get_ready

...vddk/vddk.c @@ -431,12 +431,31 @@ vddk_config_complete (void) return 0; } +#define vddk_config_help \ + "[file=]<FILENAME> (required) The filename (eg. VMDK file) to serve.\n" \ + "Many optional parameters are supported, see nbdkit-vddk-plugin(3)." + static int vddk_get_ready (void) { - VixError err; - load_library (true); + return 0; +} + +/* Defer VDDK initialization until after fork because it is known to + * create background threads from VixDiskLib_InitEx. Unfortunately + * error reporting from this callback is difficult, but we have + * already checked in ....

VDDK plugin + --run was broken because of the following sequence of events: (1) After .config_complete, server redirects stdin/stdout to /dev/null. (2) Server then calls vddk_get_ready which reexecs. (3) We restart the server from the top, but with stdin/stdout redirected to /dev/null. So saved_stdin/saved_stdout save /dev/null. (4) run_command is called which "restores" /dev/null as stdin/stdout. (5) The output of the --run option is sent to /dev/null. In...

I like this change. I think we were overloading the config_complete method before to do two different things (complete configuration; do any allocation/housekeeping necessary before we can start serving). The only questions in my mind are whether we want this before 1.18, and whether the name ("get_ready") is a good one. Rich.

If you have a plugin which either creates background threads itself or uses a library that creates background threads, it turns out you cannot create these in .get_ready (or earlier). The reason is that nbdkit forks when either daemonizing itself or using the --run option, and fork cancels all the background threads in the child process (the daemonized or captive nbdkit). The only good solution