No Linux, como posso executar um processo no qual posso voltar mais tarde para fornecer um comando após desanexar

No momento, estou desenvolvendo um aplicativo de hospedagem de servidores (principalmente para mim / para fins de aprendizado) e tudo funciona muito bem, e não sei, quantos de vocês estão familiarizados com o Counter-Strike em geral, mas inicio meu servidor e tudo está ok, mas eu desanexo (tudo está escrito no Node.js.), então não posso usar screennada, mas basicamente se eu quisesse alterar o nível no servidor, seria capaz de digitar changelevel de_dust2ou algo assim se fosse iniciar o servidor manualmente, mas como estou desanexado, não tenho como dar comandos a esse processo.

Eu li sobre FIFO e uso de soquetes Unix, mas tudo o que parece fazer é ecoar para mim, não tenho certeza se sinto falta de entender FIFO, mas achei que poderia

mkfifo /tmp/server eco "./startserver"> / tmp / server &

e depois se eu quisesse

echo "changelevel de_dust2" > /tmp/server

desculpe se não estou claro, basicamente eu tenho um processo daemon para o qual desejo enviar comandos.

— XCritics
fonte

Respostas:

Você deve certificar-se de que o processo "daemon" leia do pipe.

mkfifo /tmp/server
./startserver < /tmp/server &
sleep 10000 > /tmp/server &

Posteriormente, o que você escrever /tmp/server/aparecer na startserverentrada padrão da, por exemplo:

echo "changelevel de_dust2" > /tmp/server

Nota: o sleepcomando é necessário para manter o canal aberto, porque cada echocomando tentará fechá-lo quando terminar, possivelmente finalizando startserver.

— Dmitry Grigoryev
fonte

Obrigado pela sua resposta, startserveré algo que é um processo de longo prazo, para que não pare até que eu diga quando digito, startserver < /tmp/serverele simplesmente trava, então eu tenho que CTRL + C com isso e nada acontece. O que estou fazendo errado?

— XCritics

Adicionado o sleepcomando para abrir o canal no início. Isso deve ajudar. Pode ser necessário aumentar o atraso ou substituí-lo por catpara manter o tubo aberto para sempre.

— Dmitry Grigoryev

Incrível, isso funcionou! Mas por que funcionou?

— XCritics

Quando startservertenta ler a partir de seu STDIN, ele fica bloqueado até que alguém grave no canal. O sleep 10000 > /tmp/servercomando não escreve nada, mas abre o canal para gravação, o que é suficiente para desbloquear o processo.

— Dmitry Grigoryev

Três maneiras me vêm à mente. Enquanto o processo daemon usa stdin / out, não deve ser um problema se comunicar com ele.

se você usa screen, tmuxou solução semelhante, você não tem que separar o servidor. Você pode seguramente mantê-lo "conectado" ao console e desconectar a própria tela.
você pode usar /proc/N/fd/{0,1}a comunicação desde que possua direitos adequados, onde N é o PID do deamon, fd0 geralmente é o stdin e fd1 é stdout do processo N.
sua abordagem com um pipe nomeado (FIFO) está correta em essência, mas você está fazendo isso apenas pela metade. O que você fez foi alterar o stdout do processo para o canal, o que significa que tudo o que é impresso no stdout pelo daemon é gravado no canal de onde você pode extraí-lo, digamos, gato. O tubo é half-duplex, o que significa que ele pode conectar apenas uma entrada a uma saída. Você precisa de dois tubos, um para entrada e outro para saída. Então, o que você enviar para o daemon por meio de um canal chegará lá, enquanto a resposta passará pelo outro canal novamente para outro programa que lerá o canal.

Suponha que existem dois tubos pine pout. Você corre:

daemon <pin> faneca

Então você deve executar algo como

beicinho & gato> pin

para se comunicar. Este é um mau exemplo, ele pode ter condições de corrida, pois é assíncrono, mas espero que você entenda.

— mikky
fonte

É possível fazer isso com soquetes Unix?

— XCritics

Sim. Mas desde que você deseje usar comandos simples do console, será necessário envolvê-los em algum método com reconhecimento de soquete, como o BSD netcat (nc) e, se você estiver usando o Bash, também precisará manter pelo menos um tubo de reposição à mão como Bash, até onde sei, não pode criar um canal IPC bidirecional do tipo soquete. Assim, os comandos iria assim: daemon < pin | nc -lU socket > pinea interface ouvinte / comando seria semelhante nc -U socket ajustar as configurações nc para que ele permaneça vivo depois EOFs, EOLs, etc.

— mikky