Czy mogę przekierować dane wyjściowe do pliku dziennika i jednocześnie uruchomić proces w tle?

116

Czy mogę przekierować dane wyjściowe do pliku dziennika i jednocześnie uruchomić proces w tle?

Innymi słowy, czy mogę zrobić coś takiego?

nohup java -jar myProgram.jar 2>&1 > output.log &

Czy to nie jest rozkaz prawny? Czy też muszę ręcznie przenieść go do tła, na przykład:

java -jar myProgram.jar 2>$1 > output.log
jobs
[CTRL-Z]
bg 1
bash shell shell-script djangofan
źródło
2
Próbowałeś tego? Jaki masz błąd? Nie jestem również pewien, czy masz literówkę lub błąd w kodzie. 2>$1prawdopodobnie ma być 2>&1.
Patrick

Odpowiedzi:

171

Jednym z problemów z pierwszym poleceniem jest przekierowanie stderr do miejsca, w którym znajduje się stdout (jeśli zmieniłeś $ na a & zgodnie z sugestią w komentarzu), a następnie przekierowałeś stdout do jakiegoś pliku dziennika, ale to nie pociąga za sobą przekierowanego stderr . Musisz to zrobić w innej kolejności, najpierw wyślij stdout tam, gdzie chcesz, a następnie wyślij stderr na adres stdout pod adresem

some_cmd > some_file 2>&1 &

a następnie możesz włączyć i włączyć, aby wysłać go w tło. Do zadań można uzyskać dostęp za pomocą jobspolecenia. jobspokaże bieżące zadania i numeruje je. Następnie możesz porozmawiać o zadaniach, używając%, a następnie liczby kill %1lub więcej.

Ponadto bez znaku & na końcu możesz zawiesić polecenie za Ctrlzpomocą bgpolecenia, aby umieścić je w tle i fgprzenieść z powrotem na pierwszy plan. W połączeniu z jobspoleceniem jest to potężne.

aby wyjaśnić powyższą część dotyczącą kolejności pisania poleceń. Załóżmy, że stderr to adres 1002, stdout to adres 1001, a plik to 1008. Polecenie czyta od lewej do prawej, więc pierwszą rzeczą, którą widzi w twoim, jest 2>&1przesunięcie stderr na adres 1001, a następnie sprawdzenie, > filektóry ruch stdout do 1008, ale utrzymuje stderr na 1001. Nie wyciąga wszystkiego wskazującego na 1001 i nie przenosi go do 1008, ale po prostu odwołuje się do stdout i przenosi go do pliku.
Odwrotnie, przesuwa stdout na 1008, a następnie przesuwa stderr do punktu, na który wskazuje stdout, 1008. W ten sposób oba mogą wskazywać na pojedynczy plik.

Jacob Minshall
źródło
Wydaje się, że po tym nie mogę uchwycić pid$!
chovy
8
Warto również zauważyć: możesz użyć &> file.outdo przekierowania zarówno stdin, jak i stdout do pliku wyjściowego, co ogranicza możliwość pomyłki przy wstawianiu 2>&1niewłaściwego miejsca w linii poleceń.
Dan
14

Zatrzymywanie się <Ctrl+Z>i kontynuowanie w tle bgjest równoważne wykonywaniu z &na końcu polecenia.

Tak więc, aby uruchomić w tle i przekierować wyjście:

java -jar myProgram.jar 2> errorOutput.log > output.log &

Jeśli potrzebujesz również, aby to polecenie nie umarło po wyjściu z terminala, powinieneś użyć nohup

RSFalcon7
źródło
Rozumiem. Mówisz, że dołączony znak „&” jest zbędny?
djangofan
Po prostu cytuję stronę podręcznika. Ponieważ nohup i tak wykona polecenie w tle, wydaje się zbędne wykonywanie samego nohup w tle
RSFalcon7
10
nohup nie wykonuje polecenia w tle, musisz jawnie dołączyć&
jlliagre
3
Po przeniesieniu procesu w tło za pomocą bgmożna go odłączyć od sesji, uruchamiając disown, co powoduje, że proces nie umiera po zamknięciu terminalu.
Koen.
14 
java -jar myProgram.jar &> output.log &

Zauważ, że &>kieruje zarówno stdout, jak i stderr do output.log

Abhinav Bhatia
źródło
3
Wyjaśnienie w jednym wierszu spowoduje, że odpowiedź będzie kompletna.
anaik
2
@ abhisheknaik96 uruchamia plik jar i przekierowuje zarówno stdin, jak i stderr do output.log i czyni go procesem w tle.
P Pang
2

Zamiast używać nohup, możesz użyć ekranu. Możesz zobaczyć status programu w czasie rzeczywistym. możesz nawet zapisać wszystkie dane wyjściowe w pliku. Jest to przydatne, gdy uzyskujesz dostęp do serwera za pośrednictwem ssh, gdzie się wylogowujesz z powodu złego połączenia lub braku aktywności. Po zalogowaniu możesz kontynuować pracę od miejsca, w którym wyszedłeś. zapoznaj się z tym i tym, aby wiedzieć szczegółowo.

Mani
źródło
1

teeKomenda jest dość powszechne też.

nohup java -jar myProgram.jar | tee output.log &

trevorgrayson
źródło