0

I've also posted this question on stack overflow. here:https://stackoverflow.com/questions/55689120/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 reaches 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/
-2

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 to 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
New contributor
deck luck is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.