From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 1F7D920711 for ; Mon, 12 Aug 2019 06:31:55 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3en0tg4rUp6j for ; Mon, 12 Aug 2019 06:31:55 -0400 (EDT) Received: from smtp56.i.mail.ru (smtp56.i.mail.ru [217.69.128.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 495B521CFB for ; Mon, 12 Aug 2019 06:31:54 -0400 (EDT) Date: Mon, 12 Aug 2019 13:31:51 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH] Make `tarantoolctl start` work withiout box.cfg in init script Message-ID: <20190812103151.GA30718@atlas> References: <20190809081022.1237-1-m.melentiev@corp.mail.ru> <20190809134251.GA6081@atlas> <7EF663D6-87CA-47D6-B217-0C44746A6846@corp.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7EF663D6-87CA-47D6-B217-0C44746A6846@corp.mail.ru> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Maxim Melentiev Cc: tarantool-patches@freelists.org, k.nazarov@corp.mail.ru * Maxim Melentiev [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