From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cyril Hrubis Date: Fri, 17 Sep 2021 12:59:55 +0200 Subject: [LTP] [PATCH v2] tst_test: using SIGTERM to terminate process In-Reply-To: References: <20210519085812.27263-1-liwang@redhat.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ltp@lists.linux.it Hi! > > > I managed to reproduce this in dash. I bet that this is a bug where > > > signal handler inside dash is temporarily disabled when we install the > > > trap and if we manage to hit that window the signal is discarded. At > > > least that is my working theory. After I've installed debug prints, in > > > the cases where it hangs the signal was sent just before have installed > > > the trap. And in some cases when the signal arrives the timer process is > > > killed but the trap is not invoked. So it really looks like signal > > > handling in dash is simply broken. Not sure what we can do about bugs > > > like this apart from switching to a real programming language. > Which version of bash and dash are you testing on? > > > Thanks for the debugging. *bash* is also affected, at least some releases. > > I reproduced it also on some older SLES, with bash 4.4. > dash 0.5.11.4 and 5.1.8 on my Tumbleweed laptop are OK. > > I tested it on various my VM: > > dash *failing*: 0.5.8 (SLES), 0.5.11.3 (Tumbleweed), 0.5.11+git20200708+dd9ef66-5 (Debian), 0.5.7-4+b1 (Debian) > dash *OK*: 0.5.11.2 (SLES 15), 0.5.10.2 (CentOS) > > bash *failing*: 5.1.4-1.4 (Tumbleweed), 4.4-9.7.1 (SLES 15) > bash *ok*: 4.4-17 (SLES 15), 4.3-83 (SLES 12), 4.3-11+deb8u (Debian), 5.1-2+b3 > (Debian), 4.2.46-34 (CentOS) > > I have no idea what it causes, whether really some bash and dash versions are > buggy or it's reproducible only on certain environment. bash 5.1.8 seems to work okay, dash 0.5.11.3-r2 seems to fail here. > Any tip what to search for? Not really, apart from reading source code and figuring out exactly what happens here. I guess that we can make things more predictable and easier to read by shifting parts of the shell library to a C process. For instance if we wrote an utility that would implement all the tst_kill_test and timeout process in C we would simplify things greatly. Something as: tst_timeout_kill that would be used as: tst_timeout_kill 300 12342 ^ ^ | process group leader pid timeout in seconds That would implement both the loop for killing tests and timeout processing as well. That way we would get rid of the trap in the subshell and we would end up with a single pid for the whole timeout process and avoid the recursive sigkill to begin with. -- Cyril Hrubis chrubis@suse.cz From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7DA2C433EF for ; Fri, 17 Sep 2021 10:59:44 +0000 (UTC) Received: from picard.linux.it (picard.linux.it [213.254.12.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 17F4A61100 for ; Fri, 17 Sep 2021 10:59:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 17F4A61100 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux.it Received: from picard.linux.it (localhost [IPv6:::1]) by picard.linux.it (Postfix) with ESMTP id CC7173C8848 for ; Fri, 17 Sep 2021 12:59:41 +0200 (CEST) Received: from in-2.smtp.seeweb.it (in-2.smtp.seeweb.it [IPv6:2001:4b78:1:20::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by picard.linux.it (Postfix) with ESMTPS id B469A3C1D1E for ; Fri, 17 Sep 2021 12:59:32 +0200 (CEST) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by in-2.smtp.seeweb.it (Postfix) with ESMTPS id 9C58E600A55 for ; Fri, 17 Sep 2021 12:59:31 +0200 (CEST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id C198C2228A; Fri, 17 Sep 2021 10:59:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1631876370; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WdR/3JL1oBaVKtW+w7ncPgAUa+tTCenNFkZwsdxlJpk=; b=SEAoF+/QAY4x/y6lNM+xS8pTiTsjvn7FAOWj3DvsdVhgYehqosgfcGBlIxvpgsJZA44NEs 6mnf6uvHOlwpISD3vlG2jQJS3Uxz63WGaPgohTpMtbX0gUP2FMP7+3xQx3hSTg1f8wxeRT RELXncIAGoTDYLxoFXPYF8452+sEjXU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1631876370; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WdR/3JL1oBaVKtW+w7ncPgAUa+tTCenNFkZwsdxlJpk=; b=1HYbhKOTAzoee2NLL+lJ86OeMChHxHKe6j7Acqb3sU/3ZWF5D7o9KSJhrU3oN1AnIpsVCd N7z52FuyxMp0fNAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 9FB3A14074; Fri, 17 Sep 2021 10:59:30 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id cPFRJRJ1RGHnEQAAMHmgww (envelope-from ); Fri, 17 Sep 2021 10:59:30 +0000 Date: Fri, 17 Sep 2021 12:59:55 +0200 From: Cyril Hrubis To: Petr Vorel Message-ID: References: <20210519085812.27263-1-liwang@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Virus-Scanned: clamav-milter 0.102.4 at in-2.smtp.seeweb.it X-Virus-Status: Clean Subject: Re: [LTP] [PATCH v2] tst_test: using SIGTERM to terminate process X-BeenThere: ltp@lists.linux.it X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Test Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ltp@lists.linux.it, Joerg Vehlow Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ltp-bounces+ltp=archiver.kernel.org@lists.linux.it Sender: "ltp" Message-ID: <20210917105955.S_-8ka1lww9qYA8Fjo6pCV_Yawt_WubMdnVScqpIHQY@z> Hi! > > > I managed to reproduce this in dash. I bet that this is a bug where > > > signal handler inside dash is temporarily disabled when we install the > > > trap and if we manage to hit that window the signal is discarded. At > > > least that is my working theory. After I've installed debug prints, in > > > the cases where it hangs the signal was sent just before have installed > > > the trap. And in some cases when the signal arrives the timer process is > > > killed but the trap is not invoked. So it really looks like signal > > > handling in dash is simply broken. Not sure what we can do about bugs > > > like this apart from switching to a real programming language. > Which version of bash and dash are you testing on? > > > Thanks for the debugging. *bash* is also affected, at least some releases. > > I reproduced it also on some older SLES, with bash 4.4. > dash 0.5.11.4 and 5.1.8 on my Tumbleweed laptop are OK. > > I tested it on various my VM: > > dash *failing*: 0.5.8 (SLES), 0.5.11.3 (Tumbleweed), 0.5.11+git20200708+dd9ef66-5 (Debian), 0.5.7-4+b1 (Debian) > dash *OK*: 0.5.11.2 (SLES 15), 0.5.10.2 (CentOS) > > bash *failing*: 5.1.4-1.4 (Tumbleweed), 4.4-9.7.1 (SLES 15) > bash *ok*: 4.4-17 (SLES 15), 4.3-83 (SLES 12), 4.3-11+deb8u (Debian), 5.1-2+b3 > (Debian), 4.2.46-34 (CentOS) > > I have no idea what it causes, whether really some bash and dash versions are > buggy or it's reproducible only on certain environment. bash 5.1.8 seems to work okay, dash 0.5.11.3-r2 seems to fail here. > Any tip what to search for? Not really, apart from reading source code and figuring out exactly what happens here. I guess that we can make things more predictable and easier to read by shifting parts of the shell library to a C process. For instance if we wrote an utility that would implement all the tst_kill_test and timeout process in C we would simplify things greatly. Something as: tst_timeout_kill that would be used as: tst_timeout_kill 300 12342 ^ ^ | process group leader pid timeout in seconds That would implement both the loop for killing tests and timeout processing as well. That way we would get rid of the trap in the subshell and we would end up with a single pid for the whole timeout process and avoid the recursive sigkill to begin with. -- Cyril Hrubis chrubis@suse.cz -- Mailing list info: https://lists.linux.it/listinfo/ltp