Jak zrobić skrypt powłoki, który wysyła dane wyjściowe do procesu

Obecnie uruchamiam program konsoli serwera na ekranie, ponieważ muszę go zarówno przeczytać, jak i czasami wysyłać polecenia.

Chciałbym uruchomić aplikację jako demon w tle (start / stop przy pomocy init).

Mogę tail -fzalogować dziennik, ale to nie pozwoli mi przesłać danych wejściowych do procesu.

Czy jest jakiś sposób na skonfigurowanie tego, aby móc zarówno czytać, jak i wysyłać dane wejściowe, ale nadal mieć to w tle?

Chciałbym również móc wysyłać dane wejściowe do demona również z różnych procesów (na przykład skrypt powłoki, który mógłby wysłać polecenie „Stop \ n”).

scripting shell-script tail

— Bill K.
źródło

Tylko komentarz do każdego, kto to przeczyta - odpowiedź tutaj jest fantastyczna. Jeśli nie wiesz o nazwanych rurach, gorąco polecam przynajmniej spróbować. Korzystając z tego, mogłem uruchomić Minecraft jako usługę i wchodzić w interakcje z konsolą z innych skryptów pisząc do nazwanego potoku - dzięki czemu możliwe jest pisanie skryptów w celu zatrzymania serwera, wysyłania wiadomości do użytkowników itp. Przy jednoczesnym analizowaniu dziennika wyjściowego szukać kluczowych linii (takich jak wysyłanie wiadomości czatu zaadresowanych do użytkownika jako SMS-a)

— Bill K

Odczyt z potoku, zapis do pliku

Jeśli chcesz, aby demon odczytał dane wygenerowane przez dowolny dowolny proces, musisz podłączyć ten proces do potoku. Tutaj arbitralny proces polega na powtarzaniu poleceń i będzie przebiegał w innym kontekście. Stwórz więc nazwany potok (często nazywany fifo w kontekstach unixowych).

mkfifo /var/run/daemon.fifo
</var/run/daemon.fifo /path/to/daemond --option >daemon.log

I po prostu napisz polecenia do potoku:

echo 'FORWARD 10' >/var/run/daemon.fifo
echo 'LEFT 72' >/var/run/daemon.fifo

Jest jednak mało prawdopodobne, aby działało tak, jak jest: istnieje duża szansa, że demon zakończy działanie, gdy zobaczy koniec pliku na standardowym wejściu, co nastąpi natychmiast po zakończeniu pierwszego procesu zapisywania w potoku. Możesz użyć, tail -faby uniknąć tego problemu.

</var/run/daemon.fifo tail -c +1 -f | {
  echo $$ >/var/run/daemon.pid
  exec /path/to/daemond --option >daemon.log
}

W przypadku niektórych tailimplementacji możesz zostać ugryziony przez buforowanie: tailproces zaczeka, aż zgromadzi wystarczającą ilość bajtów, aby wyemitować dane wyjściowe. Nie sądzę, że można to rozwiązać w przyborniku POSIX; jeśli to jest problem, użyj trywialnego programu C, Perl lub Python. O ile mogę powiedzieć, tailz GNU coreutils (tak jak w Linuksie i gdzie indziej) jest bezpieczny pod tym względem.

Gdy zatrzymasz demona, echo >/var/run/daemon.fifozabije tailproces.

Uruchomienie programu na ekranie

Zamiast wywoływać demona bezpośrednio z menedżera usług (czy naprawdę używasz tylko SysV init, czy czegoś dodatkowego, takiego jak skrypty opakowania lub Upstart?), Wywołaj

screen -c daemon.screenrc -L -d -m -S daemon_name /path/to/daemond --option

Ponieważ demon nie będzie procesem potomnym menedżera usług, należy upewnić się, że wysłano sygnał do właściwego procesu. Jak to zrobić, zależy od tego, w jaki sposób demon jest uruchamiany i od czego.

Z technicznego punktu widzenia możliwe jest dołączenie działającego procesu do terminala, ale istnieje ryzyko awarii programu, więc zdecydowanie nie jest to system produkcyjny.

Ta -Lopcja powoduje, że screen zapisuje do pliku wszystko, co pojawia się w jego oknie. Nazwa pliku jest podana w daemon.screenrcz logfiledyrektywą.

— Gilles „SO- przestań być zły”
źródło

Tak naprawdę, naprawdę chciałbym móc wysyłać wiadomości na ten adres ze skryptu - może to pytanie powinienem był zadać. Obecnie po prostu uruchamiam serwer ze skryptu i mogę pisać na nim w terminalu, ale wydaje się, że powinien on działać jako usługa ...

— Bill K

@ Bill: Ok, rozumiem. Pierwszą rzeczą, która przychodzi mi do głowy, jest nazwana fajka.

— Gilles „SO- przestań być zły”

Myślę, że właśnie tego chcę @Gilles! Muszę to jednak lepiej zrozumieć. Poświęcę trochę czasu na przeglądanie stron podręcznika, aby to rozgryźć - szczerze mówiąc, bardzo mało tego (mam większość tego, co robisz i prawie nic z tego, jak to zrobiłeś) - i pomyślałem, że miałem o tym.) Moja teoria nie polegała na łączeniu się bezpośrednio z procesem, ale na stworzeniu kolejnego skryptu, który połączyłby swoje operacje wejścia / wyjścia z diamonami, aby wyglądało to tak, jakby działała oryginalna konsola, ale z możliwością aby wykonać echo „FORWARD 10” z innego skryptu w tym samym czasie.

— Bill K

Myślę, że mam tego dużo. Jeśli go podzielę, rozumiem teraz „mkfifo pipe” i „tail -f pipe | command> output”, przetestowałem je i działają. Myślę, że większość innych rzeczy, które miałeś, to sztuczki, aby uruchomić go na jednej linii - czy brakuje mi czegoś krytycznego?

— Bill K

@Bill: Możesz pisać do wewnętrznego ekranu terminala z zewnątrz (używając screena stuff polecenia ). Ale nie potrzebujesz tutaj narzutu (przetwarzania, ale przede wszystkim funkcji poznawczych) terminala, potok jest prawie wystarczający (wystarczy z małym procesem przekazywania ignorującym koniec pliku). Możesz trochę poeksperymentować z terminalem <fifo catlub <fifo tail -f | catw jednym terminalu i echo >fifo; echo >fifona drugim; Myślę, że wszystko będzie dobrze.

— Gilles „SO- przestań być zły”