Sending Command to Process Using /Proc

sending command to process using /proc

You can't do that. /proc/fd/0 is (usually) not a pipe which you can write to and give the process input.

What you need to do, is invoke the process with its stdin coming from something that IS a pipe (or socket etc) so that you can write stuff into it.

A named pipe MAY work here (see mknod(1) or mkfifo(3) ).

Otherwise, you'll need a control program which sits in front of it and uses a pair of pipes to talk to it.

Sending signals to a process opened by proc_open()

You can sending signals via PHP :

posix_kill(posix_getpid(), SIGTERM); 

How to interact with a process with its PID

procfs is something you should have a look at. It provides a lot of information on the process. Here is the manpage for proc(5).
Basically, you cd to /proc/$PID and all those pseudo files contain info you should be able to look at.

Otherwise, a good program to play with is top, or even better, htop. It can send all sorts of signals, and you can observe a lot of info (status, mem usage, cpu usage,...) It's really great.

Apart from that it's not clear what you're looking to do, so I'm staying pretty generic. If you want to do IPC (inter process communication) as sarnold said, signals might be the way to go, or mmap. (memory-mapped file)

Send signal to process from command line

As far as I understood your question you want to signal a process by its name, not by its PID. This can easily be achieved by combining the two commands:

kill -s signal $(ps -C executable)

Does it kill the process that signals?

kill can kill. It doesn't necessarily.

From man kill:

The command kill sends the specified signal to the specified
processes
or process groups.

That means, the kill command is used to **send any signal in general.

If it kills a process it means that it's similar to do exit(0), or
does the process resume after the signal is sent back?

From here:

The SIGKILL signal is used to cause immediate program termination. It
cannot be handled or ignored, and is therefore always fatal. It is
also not possible to block this signal.

If a process receives the SIGKILL signal, it terminates immediately (no destructors called, no cleanup done). The only processes that do not terminate are uninterruptible processes.

---

A full list of signals available on Linux is found here.

Sending command to java -jar using stdin via /proc/{pid}/fd/0

It's not a Java thing. What you are trying is simply not doable.

Test it like this:

Console1:

 $ cat

This will basically echo anything you type on it as soon as you hit "return".

Console2: Find the process number of your cat command. Let's say it's NNN. Do:

$ echo Something > /proc/NNN/fd/0

Switch back to Console1. You'll see "Something" on the console output, but it's not echoed.

Why? Do

$ ls -l /proc/NNN/fd

And you may understand. All three descriptors, 0 for stdin, 1 for stdout and 2 for stderr are actually symbolic links, and all point to the same pseudoterminal slave (pts) device, which is the pts associated with your first terminal.

So basically, when you write to it, you actually write to the console output, not to its input. If you read from that file, you could steal some of the input that was supposed to go to the process in the first console (you are racing for this input). That's how a character device works.

The documentation for /proc says that:

/proc/[pid]/fd/

This is a subdirectory containing one entry for each file
which the process has open, named by its file descriptor, and
which is a symbolic link to the actual file. Thus, 0 is
standard input, 1 standard output, 2 standard error, and so
on.

So these are not the actual file descriptors opened by the process. They are just links to files (or in this case, character devices) with names that indicate which descriptor they are attached to in the given process. Their main duty is to tell you whether the process has redirected its file descriptors or has opened any new ones, and which resources they point to.

But if you want an alternative way of doing this, you can use a fifo - a named pipe.

Create a fifo by doing:

$ mkfifo myfifo

Run your java program:

$ java -jar minecraft_server.jar nogui < myfifo

Open another console. write

$ cat > myfifo

Now start typing things. Switch to the first console. You'll see your server executing your commands.

Mind your end-of-files, though. Several processes can write to the same fifo, but as soon as the last one closes it, your server will receive an EOF on its standard input.

What's the best way to send a signal to all members of a process group?

You don't say if the tree you want to kill is a single process group. (This is often the case if the tree is the result of forking from a server start or a shell command line.) You can discover process groups using GNU ps as follows:

 ps x -o  "%p %r %y %x %c "

If it is a process group you want to kill, just use the kill(1) command but instead of giving it a process number, give it the negation of the group number. For example to kill every process in group 5112, use kill -TERM -- -5112.

Sending commands to an application and reading its output via file descriptor in bash

A coprocess is the appropriate tool for this job:

#!/usr/bin/env bash
case $BASH_VERSION in ''|[0-3].*|4.0*) echo "ERROR: bash 4.1+ required" >&2; exit 1;; esac

coproc btctl { bluetoothctl; }

echo "scan on" >&"${btctl[1]}"

while IFS= read -r -u "${btctl[0]}" line; do
  echo "Read line from btctl: $line" >&2
done

---

Related Topics