Avoid background processing for "dash" shell race condition bug.
Purpose
On certain systems a race condition can happen when using & (background).
This is because CMake won't wait until the command finishes as & will just let it run on background and ignore finishing.
Proposed changes
These tweaks
Avoid background processing for "dash" shell race condition bug.
## Purpose
On certain systems a race condition can happen when using & (background).
This is because CMake won't wait until the command finishes as & will just let it run on background and ignore finishing.
## Proposed changes
These tweaks
You can add echo "$SHELL" or ps -p $$ somewhere to check if this is really a dash. If it is, then I would check what launches it and think how to prevent that, because XTChain build environment should startup in bash (what you can confirm or deny with same command). It is possible, that CMake spawns dash as it is your default shell.
This command is NOT terminated by the control operator '&', so the shell does NOT execute the command in the background in a subshell.
Modified command line contains originally '&>' at the end. This construction redirects STDOUT and STDERR to /dev/null, so that there is no output from 'dd' command shown. Please check manual: https://www.gnu.org/software/bash/manual/bash.html#Redirecting-Standard-Output-and-Standard-Error
You can add `echo "$SHELL"` or `ps -p $$` somewhere to check if this is really a dash. If it is, then I would check what launches it and think how to prevent that, because XTChain build environment should startup in bash (what you can confirm or deny with same command). It is possible, that CMake spawns dash as it is your default shell.
@belliash This is indeed an issue of dash, as the &>/dev/null statement isn't POSIX compliant.
If it is, then I would check what launches it and think how to prevent that, because XTChain build environment should startup in bash (what you can confirm or deny with same command).
This is true, the issue is in the target recipe itself.
Some commands in the diskimg target are prepended with sh -c, where sh is a symlink to another shell binary (dash is the default symlink on Debian-based distributions, whereas Gentoo/Arch have bash linked as default).
Possible fixes are to either switch to a POSIX-compliant output redirection (1>/dev/null) or remove the sh invokation.
@belliash This is indeed an issue of dash, as the `&>/dev/null` statement isn't POSIX compliant.
> If it is, then I would check what launches it and think how to prevent that, because XTChain build environment should startup in bash (what you can confirm or deny with same command).
This is true, the issue is in the target recipe itself.
Some commands in the diskimg target are prepended with `sh -c`, where `sh` is a symlink to another shell binary (dash is the default symlink on Debian-based distributions, whereas Gentoo/Arch have bash linked as default).
Possible fixes are to either switch to a POSIX-compliant output redirection (1>/dev/null) or remove the `sh` invokation.
belliash
requested review from belliash 2023-11-20 07:59:49 +01:00
belliash
self-assigned this 2023-11-20 07:59:52 +01:00
Some commands in the diskimg target are prepended with sh -c, where sh is a symlink to another shell binary (dash is the default symlink on Debian-based distributions, whereas Gentoo/Arch have bash linked as default).
This is true as sh is just a symlink to 'some' shell frequently.
Possible fixes are to either switch to a POSIX-compliant output redirection (1>/dev/null) or remove the sh invokation.
This is true again, but I believe this should be 1>/dev/null 2>/dev/null as &> redirects both stdout and stderr and the meaning of this PR is to fix disk image creation under dash, not to change script behavior.
>Some commands in the diskimg target are prepended with sh -c, where sh is a symlink to another shell binary (dash is the default symlink on Debian-based distributions, whereas Gentoo/Arch have bash linked as default).
This is true as sh is just a symlink to 'some' shell frequently.
> Possible fixes are to either switch to a POSIX-compliant output redirection (1>/dev/null) or remove the `sh` invokation.
This is true again, but I believe this should be `1>/dev/null 2>/dev/null` as `&>` redirects both stdout and stderr and the meaning of this PR is to fix disk image creation under dash, not to change script behavior.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
belliash
Avoid background processing for "dash" shell race condition bug.
Purpose
On certain systems a race condition can happen when using & (background).
This is because CMake won't wait until the command finishes as & will just let it run on background and ignore finishing.
Proposed changes
These tweaks
This command is NOT terminated by the control operator '&', so the shell does NOT execute the command in the background in a subshell.
Modified command line contains originally '&>' at the end. This construction redirects STDOUT and STDERR to /dev/null, so that there is no output from 'dd' command shown. Please check manual: https://www.gnu.org/software/bash/manual/bash.html#Redirecting-Standard-Output-and-Standard-Error
You can add
echo "$SHELL"orps -p $$somewhere to check if this is really a dash. If it is, then I would check what launches it and think how to prevent that, because XTChain build environment should startup in bash (what you can confirm or deny with same command). It is possible, that CMake spawns dash as it is your default shell.@belliash This is indeed an issue of dash, as the
&>/dev/nullstatement isn't POSIX compliant.This is true, the issue is in the target recipe itself.
Some commands in the diskimg target are prepended with
sh -c, whereshis a symlink to another shell binary (dash is the default symlink on Debian-based distributions, whereas Gentoo/Arch have bash linked as default).Possible fixes are to either switch to a POSIX-compliant output redirection (1>/dev/null) or remove the
shinvokation.This is true as sh is just a symlink to 'some' shell frequently.
This is true again, but I believe this should be
1>/dev/null 2>/dev/nullas&>redirects both stdout and stderr and the meaning of this PR is to fix disk image creation under dash, not to change script behavior.Tweak disk image creation in qemu.cmaketo POSIX compliant stream redirection744e4e30ccto4c7d23000e