1

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.

11
  • We can't really help without knowing what the scripts do. Can you try and give us a reproducible example? Try removing lines from the third party script until you find the simplest version that reproduces the problem and then share that here. Also, if this is not your actual script, please show us your script. Unless this simple shell version also reproduces the problem. Does it? Commented Feb 6, 2023 at 11:00
  • Unfortunately I cannot open the third-party thing. The simple my-script.sh also reproduces the problem just like the real Python script. I can try and add say signal handling to it in in order to narrow down the problem, but I don't really know what to do exactly. Commented Feb 6, 2023 at 11:11
  • 1
    if that third-party script is a shell script, you could run it manually with xtrace/set -x enabled 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 need bash -ex ./third-party-script.sh . Or if you can edit it temporarily to add set -x at the start, that would also work. Commented Feb 6, 2023 at 11:11
  • @ilkkachu Ahh I narrowed it down to the third-party script executing bash -ic some_command. The parent script stops at that point. Commented Feb 6, 2023 at 11:25
  • @n.m. that seems really weird. bash -i opens a new shell session and bash -c runs 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 ~/.bashrc affecting 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 ~/.bashrc to 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? Commented Feb 6, 2023 at 12:09

0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.