* Why does sh in the build environment ignore SIGINT and SIGQUIT? @ 2022-05-22 8:00 Foo Chuan Wei 2022-05-22 14:14 ` Ryan Prior 2022-05-30 15:20 ` Ludovic Courtès 0 siblings, 2 replies; 6+ messages in thread From: Foo Chuan Wei @ 2022-05-22 8:00 UTC (permalink / raw) To: guix-devel The shell in the environment where packages are built ignores SIGINT and SIGQUIT. If I add `(invoke "sh" "-c" "trap")` to a custom build phase, this output is produced during the build: trap -- '' INT trap -- '' QUIT Why does the shell in the build environment need to ignore these two signals? For context, this affects the build of the smlnj package (gnu/packages/sml.scm). The resulting executable seems to inherit the signal dispositions of the shell where the executable is built, with the result that CTRL-C is ignored at the sml REPL. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why does sh in the build environment ignore SIGINT and SIGQUIT? 2022-05-22 8:00 Why does sh in the build environment ignore SIGINT and SIGQUIT? Foo Chuan Wei @ 2022-05-22 14:14 ` Ryan Prior 2022-05-23 3:14 ` Foo Chuan Wei 2022-05-30 15:20 ` Ludovic Courtès 1 sibling, 1 reply; 6+ messages in thread From: Ryan Prior @ 2022-05-22 14:14 UTC (permalink / raw) To: Foo Chuan Wei; +Cc: guix-devel ------- Original Message ------- On Sunday, May 22nd, 2022 at 8:00 AM, Foo Chuan Wei <chuanwei.foo@hotmail.com> wrote: > The shell in the environment where packages are built ignores SIGINT and > SIGQUIT. If I add `(invoke "sh" "-c" "trap")` to a custom build phase That executes a shell which traps and then immediately exits. By the next step of the build phase execution it's already gone. The shell isn't ignoring you - it's not running at all. > The resulting [smlnj] executable seems to inherit the > signal dispositions of the shell where the executable is built, with the > result that CTRL-C is ignored at the sml REPL. How would it know what some other process would do in response to a signal? Sounds extremely cursed. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why does sh in the build environment ignore SIGINT and SIGQUIT? 2022-05-22 14:14 ` Ryan Prior @ 2022-05-23 3:14 ` Foo Chuan Wei 2022-05-24 6:25 ` Foo Chuan Wei 0 siblings, 1 reply; 6+ messages in thread From: Foo Chuan Wei @ 2022-05-23 3:14 UTC (permalink / raw) To: Ryan Prior; +Cc: guix-devel On 2022-05-22 14:14 +0000, Ryan Prior wrote: > ------- Original Message ------- > On Sunday, May 22nd, 2022 at 8:00 AM, Foo Chuan Wei <chuanwei.foo@hotmail.com> wrote: > > > The shell in the environment where packages are built ignores SIGINT > > and SIGQUIT. If I add `(invoke "sh" "-c" "trap")` to a custom build > > phase > > That executes a shell which traps and then immediately exits. By the > next step of the build phase execution it's already gone. The shell > isn't ignoring you - it's not running at all. `(invoke "sh" "-c" "trap")` is merely a trivial example for demonstrating that the shell ignores SIGINT and SIGQUIT. This might be significant if the build step invokes the shell to do something more significant (e.g. to build something). Anyway, I found that this behavior is possibly related to one specified by POSIX [1]: > 2.11. Signals and Error Handling > > If job control is disabled (see the description of set -m) when the > shell executes an asynchronous list, the commands in the list shall > inherit from the shell a signal action of ignored (SIG_IGN) for the > SIGINT and SIGQUIT signals. To reproduce: Method 1: $ set +m $ bash -c 'trap' & Method 2: $ bash -c 'bash -c "trap" &' Output: trap -- '' SIGINT trap -- '' SIGQUIT Method 2 probably shows what is happening in Guix. > Sounds extremely cursed. :D Do you have a solution to this problem? [1]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why does sh in the build environment ignore SIGINT and SIGQUIT? 2022-05-23 3:14 ` Foo Chuan Wei @ 2022-05-24 6:25 ` Foo Chuan Wei 2022-05-24 23:28 ` Kaelyn 0 siblings, 1 reply; 6+ messages in thread From: Foo Chuan Wei @ 2022-05-24 6:25 UTC (permalink / raw) To: Ryan Prior, guix-devel On 2022-05-23 03:14 +0000, Foo Chuan Wei wrote: > `(invoke "sh" "-c" "trap")` is merely a trivial example for > demonstrating that the shell ignores SIGINT and SIGQUIT. This might be > significant if the build step invokes the shell to do something more > significant (e.g. to build something). > > Anyway, I found that this behavior is possibly related to one specified > by POSIX [1]: > > > 2.11. Signals and Error Handling > > > > If job control is disabled (see the description of set -m) when the > > shell executes an asynchronous list, the commands in the list shall > > inherit from the shell a signal action of ignored (SIG_IGN) for the > > SIGINT and SIGQUIT signals. Maybe not. Guix's `invoke` procedure uses Guile's `system*` procedure, which ignores SIGINT and SIGQUIT as can be seen in Guile's source code: https://git.savannah.gnu.org/cgit/guile.git/tree/libguile/posix.c?h=v3.0.8#n1524 > Do you have a solution to this problem? Guile's `system` procedure does not have this problem (compare `(system "bash -c trap")` with `(system* "bash" "-c" "trap")`). One possible solution is to replace `invoke` with `system`: diff --git a/gnu/packages/sml.scm b/gnu/packages/sml.scm index 04411c02c3..fafdba9a3f 100644 --- a/gnu/packages/sml.scm +++ b/gnu/packages/sml.scm @@ -175,10 +175,14 @@ function interface, and a symbolic debugger.") "sml.boot.amd64-unix/SMLNJ-BASIS/.cm/amd64-unix/basis-common.cm")) ;; Build. - (invoke "./config/install.sh" "-default" - (if (string=? "i686-linux" ,(%current-system)) - "32" - "64")) + (let ((exit-code + (system (string-append "./config/install.sh -default " + (if (string=? "i686-linux" + ,(%current-system)) + "32" + "64"))))) + (unless (zero? exit-code) + (error (format #f "Exit code: ~a" exit-code)))) ;; Undo the binary patch. (for-each ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Why does sh in the build environment ignore SIGINT and SIGQUIT? 2022-05-24 6:25 ` Foo Chuan Wei @ 2022-05-24 23:28 ` Kaelyn 0 siblings, 0 replies; 6+ messages in thread From: Kaelyn @ 2022-05-24 23:28 UTC (permalink / raw) To: Foo Chuan Wei; +Cc: Ryan Prior, guix-devel Hi, ------- Original Message ------- On Monday, May 23rd, 2022 at 11:25 PM, Foo Chuan Wei <chuanwei.foo@hotmail.com> wrote: > On 2022-05-23 03:14 +0000, Foo Chuan Wei wrote: > > > `(invoke "sh" "-c" "trap")` is merely a trivial example for > > demonstrating that the shell ignores SIGINT and SIGQUIT. This might be > > significant if the build step invokes the shell to do something more > > significant (e.g. to build something). > > > > Anyway, I found that this behavior is possibly related to one specified > > by POSIX [1]: > > > > > 2.11. Signals and Error Handling > > > > > > If job control is disabled (see the description of set -m) when the > > > shell executes an asynchronous list, the commands in the list shall > > > inherit from the shell a signal action of ignored (SIG_IGN) for the > > > SIGINT and SIGQUIT signals. > > > Maybe not. Guix's `invoke` procedure uses Guile's `system*` procedure, > which ignores SIGINT and SIGQUIT as can be seen in Guile's source code: > https://git.savannah.gnu.org/cgit/guile.git/tree/libguile/posix.c?h=v3.0.8#n1524 > > > Do you have a solution to this problem? > > > Guile's `system` procedure does not have this problem (compare > `(system "bash -c trap")` with `(system* "bash" "-c" "trap")`). > One possible solution is to replace `invoke` with `system`: While `system` may not show the problem that `system*`, note that they aren't strictly interchangeable. To quote https://www.gnu.org/software/guile/manual/html_node/Processes.html#index-system_002a: "system* is similar to system, but accepts only one string per-argument, and performs no shell interpretation. The command is executed using fork and execlp. Accordingly this function may be safer than system in situations where shell interpretation is not required." Cheers, Kaelyn > > diff --git a/gnu/packages/sml.scm b/gnu/packages/sml.scm > index 04411c02c3..fafdba9a3f 100644 > --- a/gnu/packages/sml.scm > +++ b/gnu/packages/sml.scm > @@ -175,10 +175,14 @@ function interface, and a symbolic debugger.") > "sml.boot.amd64-unix/SMLNJ-BASIS/.cm/amd64-unix/basis-common.cm")) > > ;; Build. > - (invoke "./config/install.sh" "-default" > - (if (string=? "i686-linux" ,(%current-system)) > - "32" > - "64")) > + (let ((exit-code > + (system (string-append "./config/install.sh -default " > + (if (string=? "i686-linux" > + ,(%current-system)) > + "32" > + "64"))))) > + (unless (zero? exit-code) > + (error (format #f "Exit code: ~a" exit-code)))) > > ;; Undo the binary patch. > (for-each ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why does sh in the build environment ignore SIGINT and SIGQUIT? 2022-05-22 8:00 Why does sh in the build environment ignore SIGINT and SIGQUIT? Foo Chuan Wei 2022-05-22 14:14 ` Ryan Prior @ 2022-05-30 15:20 ` Ludovic Courtès 1 sibling, 0 replies; 6+ messages in thread From: Ludovic Courtès @ 2022-05-30 15:20 UTC (permalink / raw) To: guix-devel Hi, Foo Chuan Wei <chuanwei.foo@hotmail.com> skribis: > The shell in the environment where packages are built ignores SIGINT and > SIGQUIT. If I add `(invoke "sh" "-c" "trap")` to a custom build phase, > this output is produced during the build: > > trap -- '' INT > trap -- '' QUIT > > Why does the shell in the build environment need to ignore these two > signals? That’s because it’s running as PID 1, which does not have default signal handlers, unlike other processes (see the discussion at <https://github.com/krallin/tini/issues/8#issuecomment-146135930>.) > For context, this affects the build of the smlnj package > (gnu/packages/sml.scm). The resulting executable seems to inherit the > signal dispositions of the shell where the executable is built, with the > result that CTRL-C is ignored at the sml REPL. Lack of proper signal handler may affect the build process of smlnj, but I don’t think it can affect the resulting executable. Which signal handlers a process running ‘smlnj’ depends on run-time factors, not on its build environment, unless the build process explicitly records the set of available signal handlers, but that would be a strange thing to do. Ludo’. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-05-30 15:21 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-22 8:00 Why does sh in the build environment ignore SIGINT and SIGQUIT? Foo Chuan Wei 2022-05-22 14:14 ` Ryan Prior 2022-05-23 3:14 ` Foo Chuan Wei 2022-05-24 6:25 ` Foo Chuan Wei 2022-05-24 23:28 ` Kaelyn 2022-05-30 15:20 ` Ludovic Courtès
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.