From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] make.sh: SIGKILL and SIGSTOP cannot be trapped Date: Wed, 16 Feb 2022 17:29:56 +0000 Message-ID: <541B5CAD-928D-44FC-88D4-24BD4236C2CE@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3883776463717973227==" List-Id: --===============3883776463717973227== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Okay. Thank you for the explanation. Reviewed-by: Michael Tremer > On 16 Feb 2022, at 17:27, Peter M=C3=BCller wr= ote: >=20 > Hello Michael, >=20 > rather cosmetic. shellcheck complains about this, and I was wondering why > a SIGSTOP'ed build caused my workstation to malfunction until a reboot the > other way. >=20 > The current "trap" command just arises false expectations... :-) >=20 > Thanks, and best regards, > Peter M=C3=BCller >=20 >> Hello, >>=20 >> Is this a cosmetic change or does this fix a real world problem? >>=20 >> -Michael >>=20 >>> On 16 Feb 2022, at 17:24, Peter M=C3=BCller = wrote: >>>=20 >>> There is no sense in instructing "trap" to catch signals it cannot trap >>> whatsoever. >>>=20 >>> Signed-off-by: Peter M=C3=BCller >>> --- >>> make.sh | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>=20 >>> diff --git a/make.sh b/make.sh >>> index 4dd068e4b..c06b4ec38 100755 >>> --- a/make.sh >>> +++ b/make.sh >>> @@ -437,7 +437,7 @@ prepareenv() { >>> fi >>>=20 >>> # Trap on emergency exit >>> - trap "exiterror 'Build process interrupted'" SIGINT SIGTERM SIGKILL SIG= STOP SIGQUIT >>> + trap "exiterror 'Build process interrupted'" SIGINT SIGTERM SIGQUIT >>>=20 >>> # Checking if running as root user >>> if [ $(id -u) -ne 0 ]; then >>> --=20 >>> 2.34.1 >>=20 --===============3883776463717973227==--