В настоящее время я занимаюсь разработкой приложения для хостинга серверов (в основном для себя / в целях обучения), и все отлично работает, а что нет, я не знаю, как многие из вас знакомы с Counter-Strike в целом, но я запускаю свой сервер и все все в порядке, но я отсоединяюсь от него (это все написано в Node.js), поэтому я не могу использовать screenили ничего, но в принципе, если бы я хотел изменить уровень на сервере, я мог бы напечатать changelevel de_dust2или что-то, если я должен был запустить сервер вручную, но так как я отсоединен, я не могу дать этому процессу никаких команд.
Я читал о FIFO и использовании Unix-сокетов, но все, что мне кажется, это отозвалось эхом, я не уверен, что не понял FIFO, но думал, что смогу
mkfifo /tmp/server echo "./startserver"> / tmp / server &
а потом, если бы я хотел
echo "changelevel de_dust2" > /tmp/server
извините, если мне не ясно, в основном у меня есть процесс-демон, которому я хочу отправлять команды.
You must make sure your "daemon" process reads from the pipe.
mkfifo /tmp/server ./startserver < /tmp/server & sleep 10000 > /tmp/server & Later on, whatever you write to /tmp/server/ appears on startserver's standard input, for example:
echo "changelevel de_dust2" > /tmp/server Note: the sleep command is necessary to keep the pipe open, because each echo command will try to close it when it ends, possibly terminating startserver.
Three ways come to my mind. As long as the daemon process uses stdin/out it shouldn't be a problem to communicate with it.
if you use screen, tmux, or similar solution, you do not have to detach the server. You can safely keep it "attached" to the console and detach the screen itself.
you can use /proc/N/fd/ for communication as long as you have proper rights, where N is the deamon's PID, fd0 is usually the stdin and fd1 is stdout of the N process.
your approach with a named pipe (FIFO) is correct in essence but you're doing it only half-right. What you did was changing the stdout of the process to the pipe, meaning that all that is printed to the stdout by the daemon gets written to the pipe from where you can extract it by, say, cat. The pipe is half-duplex meaning it can only connect one input with one output. What you need are two pipes, one for input, one for output. Then whatever you send to the daemon via one pipe will get there while the response goes via the other pipe back to another program that will read the pipe.
Assume there are two pipes pin and pout. You run:
daemon < pin >pout
Then you must run something like
cat pout & cat > pin
in order to communicate. This is a bad example, it can have race conditions since it's asynchronous but I hope you get the idea.