[tarantool-patches] Re: [PATCH] Make `tarantoolctl start` work withiout box.cfg in init script

[Konstantin Osipov <kostja@tarantool.org>]

* Maxim Melentiev <m.melentiev@corp.mail.ru> [19/08/09 21:39]:
> 
> 1) wrapper_cfg does not override config but provides defaults,
> overwriting only `username` and `background` options.

You can do the same with setenv.

> 2) If I get the suggestion right, suggested final solution should work this way:
> 
> tarantoolctl start
>   io.daemon() -- parent exits, child goes to bg
>   exec(init_script, env_with_box_cfg_overrides)
>     init_script
>       box.cfg() -- uses overrides from env

Yes.

> tarantoolctl will always return with 0 code, no mater if there is error in main script or not.
> Maybe it’s just wrong naming and it should be `io.fork` instead, allowing parent to continue
> and wait for READY=1 on NOTIFY_SOCKET.

No, the parent of io.daemon() can wait for the child to start.

> If it is expected to work this way 
> 
> tarantoolctl start
>   exec(init_script, env_with_box_cfg_overrides)
>     if (ENV.TNT_DAEMONIZE) io.daemon() -- parent exits, child goes to bg
>     init_script
>       box.cfg() -- uses overrides from env
> 
> it also won’t show errors from child process.
> 
> 3) io.daemon is expected to close STD* FDs in child process, isn’t it?
> If so - child won’t be able to show errors during startup after daemonization if any.
> Current implementation of `tarantoolctl start` shows this errors and exits with non-zero code.
> 
> 4) `tarantoolctl start` would exit before init_script is finished (actually even before it’s started).
> 
> Are this incompatibilities acceptable?

No, we need to get the same semantics as your patch and we'll find
a way to do it.

> Tarantool’s built-in toolset (tarantoolctl) does not work for app-server applications but only for DB apps.
> The changes you’re suggesting are more robust and complex, it may take significant amount of time
> to resolve all issues and consider all details. This patch solves the problem in backward-compatible way right now.
> 
> We would like to open-source modules which makes it much easier to use tarantool as app server soon.
> The issue brings a limitation: “Don’t use this module with tarantoolctl (because it’s buggy)”.

Well, your patch is not good, even though it solves your issues
now. So let's take a longer route.


-- 
Konstantin Osipov, Moscow, Russia