Otdfbt

I have a long-running server process inside a screen session on my Linux server. It's a bit unstable (and sadly not my software so I can't fix that!), so I want to script a nightly restart of the process to help stability. The only way to make it do a graceful shutdown is to go to the screen process, switch to the window it's running in, and enter the string "stop" on its control console.

Are there any smart redirection contortions I can do to make a cronjob send that stop command at a fixed time every day?

This answer doesn't solve the problem, but it's left here because 30+ people found it useful, otherwise I would have deleted it long time ago.

Write to /proc/*pid of the program*/fd/0. The fd subdirectory contains the descriptors of all the opened files and file descriptor 0 is the standard input (1 is stdout and 2 is stderr).

You can use this to output messages on the tty where a program is running, though it does not allow you to write to the program itself.

Example

Terminal 1:

[ciupicri@hermes ~]$ cat
shows on the tty but bypasses cat

Terminal 2:

[ciupicri@hermes ~]$ pidof cat
7417
[ciupicri@hermes ~]$ echo "shows on the tty but bypasses cat" > /proc/7417/fd/0

Screen based solution

Start the server like this:

# screen -d -m -S ServerFault tr a-z A-Z # replace with your server

screen will start in detached mode, so if you want to see what's going on, run:

# screen -r ServerFault

Control the server like this:

# screen -S ServerFault -p 0 -X stuff "stop^M"
# screen -S ServerFault -p 0 -X stuff "start^M"
# screen -S ServerFault -p 0 -X stuff "^D" # send EOF

(this answer is based on sending text input to a detached screen from the Unix & Linux sibling site)

Explanation of the parameters:

-d -m
 Start screen in "detached" mode. This creates a new session but doesn't
 attach to it. This is useful for system startup scripts.
-S sessionname
 When creating a new session, this option can be used to specify a meaningful
 name for the session.
-r [pid.tty.host]
-r sessionowner/[pid.tty.host]
 resumes a detached screen session.
-p number_or_name|-|=|+
 Preselect a window. This is useful when you want to reattach to a specific
 window or you want to send a command via the "-X" option to a specific
 window.
-X
 Send the specified command to a running screen session e.g. stuff.

stuff [string]

 Stuff the string string in the input buffer of the current window.
 This is like the "paste" command but with much less overhead. Without
 a parameter, screen will prompt for a string to stuff.

tmux based solution

Start the server like this:

# tmux new-session -d -s ServerFault 'tr a-z A-Z' # replace with your server

tmux will start in detached mode, so if you want to see what's going on, run:

# tmux attach-session -t ServerFault

Control the server like this:

# tmux send-keys -t ServerFault -l stop
# tmux send-keys -t ServerFault Enter
# tmux send-keys -t ServerFault -l start
# tmux send-keys -t ServerFault Enter
# tmux send-keys -t ServerFault C-d # send EOF

Explanation of the parameters:

 new-session [-AdDP] [-c start-directory] [-F format] [-n window-name] [-s
 session-name] [-t target-session] [-x width] [-y height]
 [shell-command]
 Create a new session with name session-name.

 The new session is attached to the current terminal unless -d is
 given. window-name and shell-command are the name of and shell
 command to execute in the initial window. If -d is used, -x and
 -y specify the size of the initial window (80 by 24 if not
 given).

 send-keys [-lR] [-t target-pane] key ...
 (alias: send)
 Send a key or keys to a window. Each argument key is the name of
 the key (such as `C-a' or `npage' ) to send; if the string is not
 recognised as a key, it is sent as a series of characters. The
 -l flag disables key name lookup and sends the keys literally.

Try this to start:

# screen
# cd /path/to/wd
# mkfifo cmd
# my_cmd <cmd
C-A d

And this to kill:

# cd /path/to/wd
# echo "stop" > cmd
# rm cmd

In case it helps anyone:

I had a similar problem, and as the process I was using wasn't under screen or tmux, I had to take a different approach.

I attached gdb to the xterm that my process was running in, and used call write(5, "stopn", 5) from gdb to write to the master pty file descriptor.

I found out which file descriptor to send the data to by looking at /proc/<pid>/fd for a link to /dev/ptmx and then trial and error between the two options (sending my string to both matching file descriptors seemed to cause no harm).

It turned out that the xterm process I had attached to was spawned with the spawn-new-terminal() xterm action from a keybinding, and the second ptmx file descriptor open was simply the ptmx of the parent xterm process that hadn't been closed.

Hence the trial and error calls had sent output to that other terminal.

Most xterm processes don't have two ptmx file descriptors.

This effectively typed that string into the terminal, and hence sent it along to the process running under it.

n.b. you may need to allow attaching to a running process with something like
sudo bash -c "echo 0 > /proc/sys/kernel/yama/ptrace_scope"

It is possible to send input text to a running process without running the screen utility, or any other fancy utility. And it can be done by sending this input text to the process' standard input "file" /proc/PID#/fd/0.

However, the input text needs to be sent in a special way to be read by the process. Sending the input text via the regular file write method will not cause the process to receive the text. This is because doing so will only append to that "file", but will not trigger the process to read the bytes.

To trigger the process to read the bytes, it is necessary to do an IOCTL operation of type TIOCSTI for every single byte to be sent. This will place the byte into the process' standard input queue.

This is discussed here with some examples in C, Perl, and Python:

https://unix.stackexchange.com/questions/48103/construct-a-command-by-putting-a-string-into-a-tty/48221

--

So to answer the original question asked almost 9 years ago, the cron job would need to run some small utility script / program similar to the examples people wrote for that other question, which would send the string "stopn" to that server process in the question, by sending each of the 5 bytes via an IOCTL operation of type TIOCSTI.

Of course this will only work on systems that support the TIOCSTI IOCTL operation type (like Linux), and only from the root user account, as these "files" under /proc/ are "owned" by root.

Since I cannot comment the most accepted answer of Cristian Ciupitu (of 2010), I have to put this in a separate answer:

This question was already solved in this thread: https://stackoverflow.com/questions/5374255/how-to-write-data-to-existing-processs-stdin-from-external-process

In short:

You have to start your process with a pipe for stdin which does not block nor close when the current input was written through. This can be implemented by a simple endless loop which will be piped to the process in question:

$ (while [ 1 ]; do sleep 1; done) | yourProgramToStart

I can confirm that this is different of krissi's way to open a pipe which was not working in my case. The shown solution did work instead.

You can then write to the .../fd/0 file of the process to send instructions to it. The only drawback is that you need to terminate the bash process as well which is executing the endless-loop after the server did shut down.