I have a third-party script that runs some complicated stuff.
I run everything from an ssh session (the machine is a headless VM running Ubuntu 20.04).
When I run it interactively, it runs normally.
$ ./third-party-script.sh one
<script output one>
$ ./third-party-script.sh two
<script output two>
When I run it from another script, the parent script stops when the third-party script executes for the second time.
$ cat my-script.sh
#!/bin/sh
./third-party-script.sh one
./third-party-script.sh two
$
$ ./my-script.sh
<script output one>
[1]+ Stopped ./my-script.sh
$
I can send my script to foreground and it continues normally
$ fg
<script output two>
$
What could be the reason of this behaviour and how can it be avoided? I cannot fix the third-party script or anything that it runs, I can only fix my script. (The original "my-script" is written in Python and uses os.system, I simplified it to a bare-bones shell script for this question).
I tried running the script with nohup but it didn't help.
Thanks to @ilkkachu, I have narrowed it down to the third-party script executing bash -ic some_command. So the minimal script that reproduces this in my environment is:
#!/bin/sh
bash -ic ls
bash -ic ls
sh -ic and bash -c both fix the problem. Unfortunately I cannot change the command. I need to wrap the third-party script somehow so that it stops doing this.
I tried bash -icx instead, but this doesn't narrow down the problem any further. The second bash execution stops before printing any command.
I tried to strace -f the whole thing and this is what comes in the end:
[pid 3805453] ioctl(255, TIOCGPGRP, [3805322]) = 0
[pid 3805453] rt_sigaction(SIGTTIN, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f131f36a090}, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f131f36a090}, 8) = 0
[pid 3805453] kill(0, SIGTTIN) = 0
[pid 3805321] <... wait4 resumed>0x7ffcc2d45bfc, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
[pid 3805453] --- SIGTTIN {si_signo=SIGTTIN, si_code=SI_USER, si_pid=3805453, si_uid=4437} ---
[pid 3805321] --- SIGTTIN {si_signo=SIGTTIN, si_code=SI_USER, si_pid=3805453, si_uid=4437} ---
[pid 3805453] --- stopped by SIGTTIN ---
[pid 3805321] --- stopped by SIGTTIN ---
3805453 is the second child bash running -ic ls and 3805321 is the top-level bash running my-script.sh.
It is the only line with kill(0, SIGTTIN) in the strace log. The first child bash doesn't do anything like that, only the second one does.
xtrace/set -xenabled to have the shell print the commands it executes, so you'd see what triggers the stop. Check the hashbang line to see which shell it uses and if there are any options, e.g. if there's#!/bin/bash -e, you'd needbash -ex ./third-party-script.sh. Or if you can edit it temporarily to addset -xat the start, that would also work.bash -ic some_command. The parent script stops at that point.bash -iopens a new shell session andbash -cruns a command. I am having trouble understanding why the two would be combined, but one reason might be to read the user's interactive shell initialization files. So there might be something in your~/.bashrcaffecting it. Can you try running the script as a different user (one with no.bashrc) or if that's not an option, try renaming your~/.bashrcto something else and then running the script to see if you still get the problem or if the issue is indeed something in your bashrc?