Computing desk
< January 18	<< Dec \| January \| Feb >>	January 20 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

January 19

Run command when process dies (Linux)

Lets say I have a process running that's likely to take some time. I also have a second command that I want to run, but I know that command will require the same limited resources (network bandwidth, disk access, etc) that the already running process is already swamping. Is there a way to schedule that second command to run when the first, already running, process dies? 108.21.233.20 (talk) 02:01, 19 January 2021 (UTC)[reply]

Yes. The key is to use wait(2) which is accessible in the shell by the wait command. You do not say what language you are using, so it will be difficult for me to customize the instructions.

The concept is that a parent process (such as the shell or your program which did a fork and exec) is privileged to be notified of the status of child processes. Therefore the wait system call can be arranged to notify you of these exited processes. You can wait for 'anything' or you can wait for 'a specific process'.

Once wait returns then your process has exited, and you can do additional processing, such as start up the second command. Elizium23 (talk) 02:30, 19 January 2021 (UTC)[reply]

If you are going to execute the first command, grab its process id and give it to tail which will wait for the process to exit, and then execute your second command.

$ command1 &

$ pid=$!

$ tail --pid=$pid -f /dev/null

$ command2

If the first command has already started, find it's pid using pgrep

$ tail -f --pid=$(pgrep COMMAND1_NAME) /dev/null

$ command2

Hope this helps - manya (talk) 06:25, 20 January 2021 (UTC)[reply]

Or if you are starting both commands yourself (as opposed to the first one having already been started by someone/something else), just put the two commands in a shell script one after the other. Then run the script. 85.76.65.82 (talk) 07:13, 20 January 2021 (UTC)[reply]

It is ridiculous to use tail for this purpose. Just use wait.

#!/bin/bash

sleep 10 &

pid=$!

wait $pid

echo "Waiting done, run at will" Elizium23 (talk) 07:33, 20 January 2021 (UTC)[reply]

If your script is not the parent process, and wait does not work, then use kill -0 $pid and evaluate its exit status to see if the process still exists. You can put this in a spin loop. Elizium23 (talk) 07:36, 20 January 2021 (UTC)[reply]

Why is it better to do that than:

#!/bin/sh

sleep 10

echo "yup"

Are we overthinking this or what? 85.76.65.82 (talk) 20:53, 20 January 2021 (UTC)[reply]

...It's not "overthinking" the problem..., just making some (sort of reasonable, but not universally-true) assumptions about the system: the user is not necessarily spawning processes via the bash shell; the user may want to do other CPU work, instead of stalling; the user may wish to avoid expending power and emitting heat by making the CPU execute a busy wait; and so on. The method posted by 85.76.65.82 expressly differs from the method posted by Elizium23, because 85.76.65.82 relies on blocking bash REPL logic and expressly rules out asynchronous control or dispatch to subshell; while Elizium23's method does neither of those things. If you don't know or care what those are, "the methods are darned similar," at face value. At the same time, only one of these methods (the one proposed by Elizium23) is scalable to support multiple processes, or to take advantage of multiple CPUs, and so forth.

As a general rule, bash doesn't know anything about your CPU hardware; but the linux kernel does. So even if we're looking only at the two ways we might do this in the bash shell, using only a single-CPU system - we're still comparing two "superficially-functionally-identical" effects, implemented by two different under-the-hood behaviors: (1) scheduling a wait by depending on the shell's blocking REPL implementation; and (2) dispatching to the operating system (using the shell's builtin wait or the equivalent (wait(2)), which allows the linux kernel to schedule a wait, using the most efficient hardware-optimized scheduling logic.

Per the usual "GNU-is-not-Unix" adage, the actual way that your bash shell interprets and executes wait depends on how it builds against your kernel. The same is true of the way that its REPL logic gets scheduled. It's really easy to get lost in the weeds here, but the take-away message is that wait is almost surely always the more efficient implementation. In certain cases, the worst-case scenario, the difference in efficiency (and power expenditure) can be catastrophically huge. "We all hope" that your computer got installed with a version of linux and bash that were designed and tested and optimized by detail-oriented professionals - but ... we're talking about free software. Components like your linux kernel - and the shell that you use to communicate with it - are usually distributed under a term of service that expressly disavows any warranty of correct operation, fitness for any purpose, freeness from defects, and so forth.

So, use the wait method (or its variants). It will probably be more efficient. For most users on most computers, the efficiency difference is very small - perhaps too small to realistically characterize. For other users, the difference is huge.

Nimur (talk) 21:50, 20 January 2021 (UTC)[reply]

You just put them in a script and run the script.

#!/bin/sh
myprogram1
myprogram2

wait is a shell builtin that you use when running background jobs from your shell, using job control, and want to wait on them to terminate. If you don't start a command in the background using &, it runs in the foreground and the shell waits on it to complete. Note that this will run both commands regardless of whether the first aborts abnormally. We can add error handling if needed. For more on the general topic read this. Also, it's possible a different solution might be more useful. If the programs don't depend on each other, and you just want to avoid loading down your machine, try just running them at a high niceness. On Linux you can ionice them as well. --47.152.93.24 (talk) 04:10, 21 January 2021 (UTC)[reply]

Phone spoofing

I (in the UK) got (yet another) spam phone call today and I used the "who called me" option after the call to get a UK number. I tried phoning it to see what happened and it was answered by what sounded like a pleasant lady and not an automated robot. Is it possible to fake the "called from" number that you get using BT's 1471 "who called me" service? -- SGBailey (talk) 14:06, 19 January 2021 (UTC)[reply]

@SGBailey: Yes. See Caller_ID_spoofing. According to that article, there is a large fine for doing this in the UK, but I don't know how it is enforced. RudolfRed (talk) 15:51, 19 January 2021 (UTC)[reply]

Don't see how it could be considering many VoIP services allow you to modify your Caller ID and those accounts could easily be set up fraudulently or without any checks at all ✨ Ed talk! ✨ 17:14, 19 January 2021 (UTC)[reply]

The PSTN is built on a web of trust that is, nowadays, sorely misplaced. Back in the heyday of phone communications, interchanges and switches could trust one another not to be playing tricks or being hacked or something, but the phone system was not built to have malicious players, providers, or whole countries attached.

See STIR/SHAKEN for a modern effort to combat the spoofing. Attempts are underway. Elizium23 (talk) 17:57, 19 January 2021 (UTC)[reply]