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 8DE7C22E4F for ; Mon, 12 Aug 2019 09:01:54 -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 1nIoHQRCWAQX for ; Mon, 12 Aug 2019 09:01:54 -0400 (EDT) Received: from smtp34.i.mail.ru (smtp34.i.mail.ru [94.100.177.94]) (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 E6D8622E43 for ; Mon, 12 Aug 2019 09:01:53 -0400 (EDT) From: Georgy Kirichenko Subject: [tarantool-patches] Re: [PATCH] Make `tarantoolctl start` work withiout box.cfg in init script Date: Mon, 12 Aug 2019 16:01:35 +0300 Message-ID: <5668311.GLNk2tWfSB@localhost> In-Reply-To: <20190812103151.GA30718@atlas> References: <20190809081022.1237-1-m.melentiev@corp.mail.ru> <7EF663D6-87CA-47D6-B217-0C44746A6846@corp.mail.ru> <20190812103151.GA30718@atlas> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2028630.GQRBCpQize"; micalg="pgp-sha256"; protocol="application/pgp-signature" 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: tarantool-patches@freelists.org Cc: Konstantin Osipov , Maxim Melentiev , k.nazarov@corp.mail.ru --nextPart2028630.GQRBCpQize Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, August 12, 2019 1:31:51 PM MSK Konstantin Osipov wrote: > * Maxim Melentiev [19/08/09 21:39]: > > 1) wrapper_cfg does not override config but provides defaults, > > overwriting only `username` and `background` options. >=20 > You can do the same with setenv. >=20 > > 2) If I get the suggestion right, suggested final solution should work > > this way: > >=20 > > tarantoolctl start > >=20 > > io.daemon() -- parent exits, child goes to bg which way you suggest to use here to control execution state > > exec(init_script, env_with_box_cfg_overrides) here to > > =20 > > init_script > > =20 > > box.cfg() -- uses overrides from env >=20 > Yes. >=20 > > tarantoolctl will always return with 0 code, no mater if there is error= in > > main script or not. Maybe it=E2=80=99s just wrong naming and it should = be > > `io.fork` instead, allowing parent to continue and wait for READY=3D1 on > > NOTIFY_SOCKET. >=20 > No, the parent of io.daemon() can wait for the child to start. What you mean for the word "start" - a process is created, a special event= =20 happened or something else? >=20 > > If it is expected to work this way > >=20 > > tarantoolctl start > >=20 > > exec(init_script, env_with_box_cfg_overrides) > > =20 > > if (ENV.TNT_DAEMONIZE) io.daemon() -- parent exits, child goes to bg > > init_script > > =20 > > box.cfg() -- uses overrides from env > >=20 > > it also won=E2=80=99t show errors from child process. > >=20 > > 3) io.daemon is expected to close STD* FDs in child process, isn=E2=80= =99t it? > > If so - child won=E2=80=99t 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. > >=20 > > 4) `tarantoolctl start` would exit before init_script is finished > > (actually even before it=E2=80=99s started). > >=20 > > Are this incompatibilities acceptable? >=20 > No, we need to get the same semantics as your patch and we'll find > a way to do it. >=20 > > Tarantool=E2=80=99s built-in toolset (tarantoolctl) does not work for a= pp-server > > applications but only for DB apps. The changes you=E2=80=99re suggestin= g are more > > robust and complex, it may take significant amount of time to resolve a= ll > > issues and consider all details. This patch solves the problem in > > backward-compatible way right now. > >=20 > > We would like to open-source modules which makes it much easier to use > > tarantool as app server soon. The issue brings a limitation: =E2=80=9CD= on=E2=80=99t use > > this module with tarantoolctl (because it=E2=80=99s buggy)=E2=80=9D. > Well, your patch is not good, even though it solves your issues > now. So let's take a longer route. The biggest issue I see we don't have any clue how to control application o= n=20 each stage of it's life. How could application to report an error or unwant= ed=20 state right after daemonization (or even after READY=3D1 written) but befor= e=20 application is really initialized. We do not have even logging here (logger= is=20 initialized while box.cfg fired). I think we need a framework which allows to customize and to control=20 application which includes logging and application state. --nextPart2028630.GQRBCpQize Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEFZT35EtIMRTDS5hJnoTdFFzh6LUFAl1RYy8ACgkQnoTdFFzh 6LWi6gf/QhdW20b53JljJ8/Lea/ooiJuLNJp+Zlhbo8/l/KBKvS7h09dt6COxoGO AaozbGaYki00PiGKCUThB0hl08mj/NSwveKvw9pd92BD08z2R1xtJpvPPzQSgVvg fmGQ24D6zGIySIUsdZO181ep4GuHYv+rFRmf7MqvaSwD7YOHENkliL/0kAUoUDx5 4ZFalt2G+Yw5x8vDRIp8ljnydTltXfR9Zvl9D0TQJrLAIShhSIVE/D6yC3pPS0kQ pStuYn6+QlGo/2YL4r3dsZPK9RkPzEhD5jcUzPfyYh0KapBldqNYRjSswbPk8j2f Tnts4PM9CRDaTtD2KohVk+P7fgjzLw== =8ce8 -----END PGP SIGNATURE----- --nextPart2028630.GQRBCpQize--