Identical scripts, same permissions, one hangs one doesnt, How? Why? - linux

Question

I've also posted this question on Super User, here: https://superuser.com/questions/1425657/identical-scripts-same-permissions-one-hangs-one-doesnt-how-why. Please answer on the site you believe the question is most appropriate for. This will help me learn which site I should use. Thank you.
I always forget the name of the inxi command so some time ago I created a bash script called sysinfo- (note the '-' at the end to distinguish my script from the linux command sysinfo.)
$ cat ~/scripts/sysinfo-
#!/bin/bash
# DESCRIPTION
#
# Display system info at the command promp
#
# Main Program
echo -e "#############\n# inxi -b #\n#############\n"
/usr/bin/inxi -b
echo -e "############"
This script stopped working when I upgraded my system and inxi was upgraded to version 3.0.27
The script hangs when it reached the inxi command and must be killed with CTRL+C
The developer of inxi advised me to upgrade it to version 3.0.33 which I did. Unfortunately upgrading has not changed the results when running the original script. HOWEVER, after some testing I have discovered something I can't explain: An exact copy of my script runs successfully when the original does not!?
jesse#Limbo ~ $ ~/scripts/sysinfo-
#############
# inxi -b #
#############
^C
jesse#Limbo ~ $ cat ~/scripts/sysinfo- > /tmp/inxi.test
jesse#Limbo ~ $ chmod +x /tmp/inxi.test
jesse#Limbo ~ $ /tmp/inxi.test
#############
# inxi -b #
#############
System: Host: Limbo Kernel: 4.15.0-47-generic x86_64 bits: 64 Desktop: Cinnamon 4.0.10 Distro: Linux Mint 19 Tara
Machine: Type: Desktop System: MSI product: MS-7823 v: 1.0 serial: <root required>
Mobo: MSI model: CSM-H87M-G43 (MS-7823) v: 1.0 serial: <root required> BIOS: American Megatrends v: 1.6
date: 02/22/2014
CPU: Quad Core: Intel Core i7-4790 type: MT MCP speed: 3879 MHz min/max: 800/4000 MHz
Graphics: Device-1: NVIDIA GM107GL [Quadro K2200] driver: nvidia v: 390.116
Display: x11 server: X.Org 1.19.6 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa
resolution: 1920x1080~60Hz, 1280x1024~60Hz
OpenGL: renderer: Quadro K2200/PCIe/SSE2 v: 4.6.0 NVIDIA 390.116
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Drives: Local Storage: total: 14.44 TiB used: 8.32 TiB (57.7%)
Info: Processes: 316 Uptime: 56m Memory: 31.34 GiB used: 4.80 GiB (15.3%) Shell: inxi.test inxi: 3.0.33
############
jesse#Limbo ~ $ diff ~/scripts/sysinfo- /tmp/inxi.test
jesse#Limbo ~ $ ls -l ~/scripts/sysinfo- /tmp/inxi.test
-rwxr-x--- 1 jesse jesse 187 Apr 15 18:46 /home/jesse/scripts/sysinfo-
-rwxr-x--- 1 jesse jesse 187 Apr 15 19:09 /tmp/inxi.test
jesse#Limbo ~ $ md5sum ~/scripts/sysinfo- /tmp/inxi.test
a1356223d7bacb6d5b6d74cf44d733f2 /home/jesse/scripts/sysinfo-
a1356223d7bacb6d5b6d74cf44d733f2 /tmp/inxi.test
How is this possible?
If it was some sort of corruption of the original file wouldn't diff pick that up? How would I check this?
Is it possible for there to have been some sort of policy file created automatically, because I haven't made one, that prevents inxi from running from within a script in ~/scripts??
BIGO!!
jesse#Limbo ~ $ mv /tmp/inxi.test ~/scripts/
jesse#Limbo ~ $ ~/scripts/inxi.test
#############
# inxi -b #
#############
^C
Might this be an apparmor policy perhaps?
jesse#Limbo ~ $ apparmor_status | grep inxi
yields no results.
I tried placing env in both ~/scripts/sysinfo- and /tmp/inxi.test
#!/bin/bash
# DESCRIPTION
#
# Display system info at the command promp
#
env
# Main Program
echo -e "#############\n# inxi -b #\n#############\n"
/usr/bin/inxi -b
echo -e "############"
but the output of env from both scripts was identical.
jesse#Limbo ~ $ diff ~/scripts/sysinfo- /tmp/inxi.test
jesse#Limbo ~ $ ~/scripts/sysinfo- > /tmp/sysinfo.output
^C
jesse#Limbo ~ $ /tmp/inxi.test > /tmp/inxi.test.output
jesse#Limbo ~ $ diff /tmp/sysinfo.output /tmp/inxi.test.output
61a62,75
> System: Host: Limbo Kernel: 4.15.0-47-generic x86_64 bits: 64 Desktop: Cinnamon 4.0.10 Distro: Linux Mint 19 Tara
> Machine: Type: Desktop System: MSI product: MS-7823 v: 1.0 serial: <root required>
> Mobo: MSI model: CSM-H87M-G43 (MS-7823) v: 1.0 serial: <root required> BIOS: American Megatrends v: 1.6
> date: 02/22/2014
> CPU: Quad Core: Intel Core i7-4790 type: MT MCP speed: 1355 MHz min/max: 800/4000 MHz
> Graphics: Device-1: NVIDIA GM107GL [Quadro K2200] driver: nvidia v: 390.116
> Display: x11 server: X.Org 1.19.6 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa
> resolution: 1920x1080~60Hz, 1280x1024~60Hz
> OpenGL: renderer: Quadro K2200/PCIe/SSE2 v: 4.6.0 NVIDIA 390.116
> Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
> Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
> Drives: Local Storage: total: 14.44 TiB used: 8.32 TiB (57.7%)
> Info: Processes: 315 Uptime: 1h 40m Memory: 31.34 GiB used: 4.97 GiB (15.9%) Shell: inxi.test inxi: 3.0.33
> ############
As you can see the issue is not a problem running bash scripts from ~/scripts but only with running inxi from a script in ~/scripts
~/scripts happens to be a bind mounted directory on my system. Perhaps that is the problem?
BINGO!!
jesse#Limbo ~ $ mv ~/scripts/sysinfo- ~/
jesse#Limbo ~ $ ~/sysinfo-
#############
# inxi -b #
#############
System: Host: Limbo Kernel: 4.15.0-47-generic x86_64 bits: 64 Desktop: Cinnamon 4.0.10 Distro: Linux Mint 19 Tara
Machine: Type: Desktop System: MSI product: MS-7823 v: 1.0 serial: <root required>
Mobo: MSI model: CSM-H87M-G43 (MS-7823) v: 1.0 serial: <root required> BIOS: American Megatrends v: 1.6
date: 02/22/2014
CPU: Quad Core: Intel Core i7-4790 type: MT MCP speed: 900 MHz min/max: 800/4000 MHz
Graphics: Device-1: NVIDIA GM107GL [Quadro K2200] driver: nvidia v: 390.116
Display: x11 server: X.Org 1.19.6 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa
resolution: 1920x1080~60Hz, 1280x1024~60Hz
OpenGL: renderer: Quadro K2200/PCIe/SSE2 v: 4.6.0 NVIDIA 390.116
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Drives: Local Storage: total: 14.44 TiB used: 8.33 TiB (57.7%)
Info: Processes: 322 Uptime: 1h 52m Memory: 31.34 GiB used: 5.36 GiB (17.1%) Shell: sysinfo- inxi: 3.0.33
############
But hang on...
jesse#Limbo ~ $ mv ~/sysinfo- ~/scripts/
jesse#Limbo ~ $ cp ~/scripts/sysinfo- ~/
jesse#Limbo ~ $ chmod +x ~/sysinfo-
jesse#Limbo ~ $ ~/sysinfo-
#############
# inxi -b #
#############
^C
HUH ????
I moved the script back to the bind mounted ~/scripts directory, then copied (rather than moved) it to ~/, made the new file executable, and... inxi hangs!
Surely this behavior must be coming from a policy somewhere that is able to tell the difference between a file moved and a file copied. A program run from within a bash script rather than from the command line. What else besides apparmor could be capable of doing this??
jesse#Limbo ~ $ cd ~/scripts/
jesse#Limbo ~/scripts $ inxi -b
System: Host: Limbo Kernel: 4.15.0-47-generic x86_64 bits: 64 Desktop: Cinnamon 4.0.10 Distro: Linux Mint 19 Tara
Machine: Type: Desktop System: MSI product: MS-7823 v: 1.0 serial: <root required>
Mobo: MSI model: CSM-H87M-G43 (MS-7823) v: 1.0 serial: <root required> BIOS: American Megatrends v: 1.6
date: 02/22/2014
CPU: Quad Core: Intel Core i7-4790 type: MT MCP speed: 1500 MHz min/max: 800/4000 MHz
Graphics: Device-1: NVIDIA GM107GL [Quadro K2200] driver: nvidia v: 390.116
Display: x11 server: X.Org 1.19.6 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa
resolution: 1920x1080~60Hz, 1280x1024~60Hz
OpenGL: renderer: Quadro K2200/PCIe/SSE2 v: 4.6.0 NVIDIA 390.116
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Drives: Local Storage: total: 14.44 TiB used: 8.33 TiB (57.7%)
Info: Processes: 315 Uptime: 2h 01m Memory: 31.34 GiB used: 4.96 GiB (15.8%) Shell: bash inxi: 3.0.33
I can't see how the directory permissions could be having any effect
jesse#Limbo ~/scripts $ ls -ld /tmp/ ~/scripts/ ~/
drwxr-x--- 194 jesse jesse 20480 Apr 15 20:06 /home/jesse/
drwxrwx--- 18 jesse jesse 12288 Apr 15 20:06 /home/jesse/scripts/
drwxrwxrwt 20 root root 24576 Apr 15 20:32 /tmp/

Answer 1

Has anyone discovered the dmidecode, lshw, lspci, lsusb, lsblk, or blkid utilities attempting to call back the parent_script? No. For that matter any UNIX or Linux utility doing a call back to the parent_script. No. Surprise, surprise, surprise, the newer inxi version does.
The inxi developer believes it is perfectly normal to do a call back on the parent_script without any intimate knowledge of the parent_script. Common sense would be to never do a call back on the parent_script unless you have working knowledge of that script and how it will behave. You are just asking for a vicious recursive loop. If the vicious loop is left running long enough it could fill up the Linux proc table or exhausted all available memory. And the inxi developer has made a fundamental change to inxi using very bad assumptions and created this scenario.
The previous 2.x version of inxi never performed a call back on the parent_script. I can imagine many users or system admins have been using the inxi utility in a monthly script to help document their server(s). And, with the inxi 2.x it was properly working for them.
The 3.x version of the inxi utility changed the foundational behavior. Now, inxi will perform a call back to the parent_script --version. The inxi developer assumes the parent_script will respond in kind to the --version argument. Why would anyone expect the --version call back when the 2.x version of inxi fundamental behavior did not do this? This can be very nasty for a cronjob script.
The 3.x version has a very fundamental change that will catch many users off guard with a vicious recursive loop. I attempted to get the inxi developer to explain why he would change an existing foundational behavior, and what useful purpose does the parent_script --version provide. Good luck getting an answer.
How to reproduce the problem
In my example the /home/temp/bin directory resides in my PATH.
Place this simple "dltest" script in your one of your PATH directories, and it will reproduce the problem:
# cat dltest
#!/bin/bash
# Open another terminal and use ps -ft /dev/pts/? to view the spawned process.
echo -e "\nUsing `tty`.\nSleeping yawn. Taking five seconds...\n" ; sleep 5
echo -e "\nStarting inxi -Ixxx\n"
# for a test use a very basic inxi.
/usr/bin/inxi -Ixxx
$ pwd
/home/temp/bin
$
$ ./dltest
Using /dev/pts/0.
Sleeping yawn. Taking five seconds...
Starting inxi_3.0.32
Concurrently using another terminal:
$ ps -ft pts/0
UID PID PPID C STIME TTY TIME CMD
temp 1820 1816 0 11:02 pts/0 00:00:00 bash
temp 13068 1820 0 14:28 pts/0 00:00:00 /bin/bash ./dltest
temp 13070 13068 0 14:28 pts/0 00:00:00 sleep 5
$ ps -ft pts/0
UID PID PPID C STIME TTY TIME CMD
temp 1820 1816 0 11:02 pts/0 00:00:00 bash
temp 13068 1820 0 14:28 pts/0 00:00:00 /bin/bash ./dltest
temp 13072 13068 18 14:29 pts/0 00:00:00 /usr/bin/perl /usr/bin/inxi
temp 13081 13072 0 14:29 pts/0 00:00:00 sh -c /home/temp/bin/dltest --version 2>/dev/null
temp 13082 13081 0 14:29 pts/0 00:00:00 /bin/bash /home/temp/bin/dltest --version
temp 13084 13082 0 14:29 pts/0 00:00:00 sleep 5
# The longer it runs the deeper it will get.
$ ps -ft pts/0
UID PID PPID C STIME TTY TIME CMD
temp 1820 1816 0 11:02 pts/0 00:00:00 bash
temp 13622 1820 0 14:48 pts/0 00:00:00 /bin/bash ./dltest
temp 13625 13622 1 14:48 pts/0 00:00:00 /usr/bin/perl /usr/bin/inxi -tty -Ixxx
temp 13634 13625 0 14:48 pts/0 00:00:00 sh -c /home/temp/bin/dltest --version 2>/dev/null
temp 13635 13634 0 14:48 pts/0 00:00:00 /bin/bash /home/temp/bin/dltest --version
temp 13638 13635 1 14:48 pts/0 00:00:00 /usr/bin/perl /usr/bin/inxi -tty -Ixxx
temp 13647 13638 0 14:48 pts/0 00:00:00 sh -c /home/temp/bin/dltest --version 2>/dev/null
temp 13648 13647 0 14:48 pts/0 00:00:00 /bin/bash /home/temp/bin/dltest --version
temp 13652 13648 2 14:48 pts/0 00:00:00 /usr/bin/perl /usr/bin/inxi -tty -Ixxx
temp 13661 13652 0 14:48 pts/0 00:00:00 sh -c /home/temp/bin/dltest --version 2>/dev/null
temp 13662 13661 0 14:48 pts/0 00:00:00 /bin/bash /home/temp/bin/dltest --version
temp 13665 13662 20 14:48 pts/0 00:00:00 /usr/bin/perl /usr/bin/inxi -tty -Ixxx
temp 13674 13665 0 14:48 pts/0 00:00:00 sh -c /home/temp/bin/dltest --version 2>/dev/null
temp 13675 13674 0 14:48 pts/0 00:00:00 /bin/bash /home/temp/bin/dltest --version
temp 13677 13675 0 14:48 pts/0 00:00:00 sleep 5
temp#lm19:~$
To prevent this vicious loop you can add this workaround at the top of your script.
if [[ "${1}" == "--version" ]] ; then
# work around for inxi_3.0.32 parent --version anomaly
exit 1
fi

Answer 2

You can create a new script that first creates a temporary copy of the original script and then runs the temporary script for you.
So you could name the script ~/scripts/sysinfo2 and it would look like this:
#!/bin/bash
cat $HOME/scripts/sysinfo- > /tmp/inxi.test
chmod +x /tmp/inxi.test
/tmp/inxi.test
Don't forget to make it executable: chmod +x ~/scripts/sysinfo2 and then you can run
~/scripts/sysinfo2
and it should execute without hanging up.