Как я могу использовать команду nohup, не получая nohup.вышел?
У меня проблема с командой нохупа.
Когда я выполняю свою работу, у меня есть много данных. Выход никакой.выход становится слишком большим, и мой процесс замедляется. Как я могу выполнить эту команду, не получая nohup.вышел?

Ответы - Как я могу использовать команду nohup, не получая nohup.вышел? / How do I use the nohup command without getting nohup.out?

02.05.2012 10:39:52
Возможно, вы захотите использовать программу отсоединения . Вы используете его, как nohup
, но он не производит выходной журнал, если вы не скажете ему. Вот человек-страница:
NAME
detach - run a command after detaching from the terminal
SYNOPSIS
detach [options] [--] command [args]
Forks a new process, detaches is from the terminal, and executes com‐
mand with the specified arguments.
OPTIONS
detach recognizes a couple of options, which are discussed below. The
special option -- is used to signal that the rest of the arguments are
the command and args to be passed to it.
-e file
Connect file to the standard error of the command.
-f Run in the foreground (do not fork).
-i file
Connect file to the standard input of the command.
-o file
Connect file to the standard output of the command.
-p file
Write the pid of the detached process to file.
EXAMPLE
detach xterm
Start an xterm that will not be closed when the current shell exits.
AUTHOR
detach was written by Robbert Haarman. See http://inglorion.net/ for
contact information.
Заметьте, я не имею никакого отношения к автору программы. Я только удовлетворенный пользователь программы.


02.05.2012 10:41:25
Вы пробовали перенаправить все три потока ввода-вывода:
nohup ./yourprogram > foo.out 2> foo.err < /dev/null &

>
/dev/null, а не

< /dev/null
перенаправляет стандартный ввод для nohup
. Linux этого не требует, но POSIX допускает поведение, при котором nohup
не может работать в фоновом режиме, если его стандартный вход подключен к терминалу. Примерами таких систем являются BSD и OS X.

02.05.2012 10:42:31
nohup и пишет только для /dev/null
, если выход находится в противном случае на клемме. Если вы перенаправляете выходные данные команды куда - то еще - включая /dev/null
-это то, куда она идет вместо этого.
nohup command >/dev/null 2>&1 # doesn't create nohup.out
Если вы используете nohup
, это, вероятно, означает, что вы хотите запустить команду в фоновом режиме, поставив другой &
в конце всего процесса:
nohup command >/dev/null 2>&1 & # runs in background, still doesn't create nohup.out
В Linux запуск задания с nohup
также автоматически закрывает его входные данные. В других системах, особенно BSD и macOS, это не так, поэтому при работе в фоновом режиме может потребоваться закрыть ввод вручную. В то время как закрытие ввода не оказывает никакого влияния на создание или нет /dev/null
, это позволяет избежать еще одной проблемы: если фоновый процесс пытается прочитать что-либо из стандартного ввода, он будет делать паузу, ожидая, пока вы вернете его на передний план и наберете что-то. Так что экстра-безопасная версия выглядит следующим образом:
nohup command </dev/null >/dev/null 2>&1 & # completely detached from terminal
Обратите внимание, однако, что это не мешает команде напрямую обращаться к терминалу и не удаляет ее из группы процессов вашей оболочки. Если вы хотите сделать последнее, и вы запускаете bash, ksh или zsh, вы можете сделать это, запустив disown
без аргументов в качестве следующей команды. Это будет означать, что фоновый процесс больше не связан с "заданием" оболочки и не будет иметь никаких сигналов, передаваемых ему из оболочки. (Обратите внимание на различие: процесс disown ed не получает сигналов, автоматически пересылаемых ему родительской оболочкой , но без
nohup
он все равно будет получать сигнал nohup
, отправленный другими средствами, такими как команда ручного HUP
. Процесс nohup
'ed игнорирует все nohup
, HUP
, 2>>logfile
, <<
) и операторы трубы ( >
) делают.
Труба-самая простая из них... <
организует так, чтобы стандартный вывод |
подавался непосредственно на стандартный ввод command1 | command2
. Это очень удобная схема, которая привела к определенному шаблону проектирования в инструментах UNIX (и объясняет существование стандартной ошибки, которая позволяет программе отправлять сообщения пользователю, даже если ее вывод идет в следующую программу в конвейере). Но вы можете только передать стандартный вывод на стандартный вход; вы не можете отправить любые другие файловые дескрипторы в канал без некоторого жонглирования.
Операторы перенаправления более дружелюбны в том, что они позволяют вам указать, какой файловый дескриптор перенаправлять. Таким command1
считывает стандартный ввод из файла с именем command2
, а 0<infile
добавляет стандартную ошибку в конец файла с именем infile
. Если вы не зададите число, то по умолчанию входное перенаправление будет равно fd 0 (2>>logfile
равно logfile
), а выходное перенаправление-fd 1 (<
равно 0<
).
Кроме того, вы можете объединить файловые дескрипторы вместе: >
означает "отправить стандартную ошибку везде, где происходит стандартный вывод". Это означает, что вы получаете один поток вывода, который включает в себя как стандартный выход, так и стандартную ошибку, смешанную без возможности их разделения, но это также означает, что вы можете включить стандартную ошибку в канал.
Поэтому последовательность 1>
означает "направить стандартный вывод в 2>&1
" (который представляет собой специальное устройство, которое просто выбросит все, что вы напишите это) ", а затем отправить стандартное сообщение об ошибке, где стандартный вывод идет" (который мы только что убедились, был 2>&1
). В принципе, "выбросьте все, что эта команда записывает в любой файловый дескриптор".
Когда nohup
обнаруживает, что ни его стандартная ошибка, ни вывод не присоединены к терминалу, он не утруждает себя созданием /dev/null
, но предполагает, что вывод уже перенаправлен туда, куда хочет пользователь.
Устройство nohup
также работает для ввода; если вы выполняете команду с nohup.out
, то любая попытка этой команды прочитать из стандартного ввода немедленно столкнется с концом файла. Обратите внимание, что синтаксис слияния здесь не будет иметь такого же эффекта; он работает только для указания файлового дескриптора на другой, открытый в том же направлении (вход или выход). Оболочка позволит вам сделать /dev/null
, но это приведет к созданию процесса с дескриптором входного файла, открытым в выходном потоке, поэтому вместо того, чтобы просто нажать конец файла, любая попытка чтения вызовет фатальную ошибку "недопустимый дескриптор файла".




nohup
, " если процесс позже попытается прочитать что-либо из стандартного ввода, он остановится, ожидая, пока вы вернете его на передний план и наберете что-то.- это кажется неправильным. Вместо nohup
закрывает стандартный ввод (программа не сможет прочитать ни одного ввода, даже если он выполняется на переднем плане. он не остановлен, но получит код ошибки или EOF).

nohup
не закрывает стандартный вход автоматически. Обратите внимание, что nohup
это не оболочка, а двоичная утилита.

nohup
отличается для linux и для BSD или OS X?

awk
разные, sed
отличается, nohup
другая...

</dev/null
? Также смотрите 0>/dev/null
unix.stackexchange.com/a/266247

0>/dev/null
, то он, как правило, будет иметь тот же эффект, >/dev/null <&1
, о котором я упоминал.

soffice -invisible
из своего скрипта, используя упомянутый синтаксис, а затем сплю в течение 10. Если я нажму Ctrl-C в течение этого периода, soffice остановится. Замена nohup на setsid сделала его работоспособным.

/dev/tty
, это может говорить в терминал независимо от того, где stdin
, stdout
и stderr
указаны.В этом случае, однако, поскольку setsid
фиксирует его, похоже, добавленные в процессе группы, содержащей оболочки, а не терминал.




&
На панели избавит вас от необходимости использовать ctrl-c
, если это имеет для вас значение.


вывода some_command, включая ошибку.

13.03.2015 01:35:55
sudo bash -c "nohup /opt/viptel/viptel_bin/log.sh $* &> /dev/null" &
Перенаправление вывода sudo приводит к тому, что sudo повторно запрашивает пароль, поэтому для выполнения этого варианта необходим неудобный механизм.



28.09.2018 11:16:25
Если у вас есть оболочка BASH на вашем mac / linux перед вами, вы можете попробовать следующие шаги, чтобы понять перенаправление практически :
Создайте 2-строчный скрипт под названием zz.sh
#!/bin/bash
echo "Hello. This is a proper command"
junk_errorcommand
- Выходные данные команды echo поступают в STDOUT filestream (файловый дескриптор 1).
- Выходные данные команды error поступают в файловый поток STDERR (файловый дескриптор 2)
В настоящее время простое выполнение сценария отправляет на экран как STDOUT, так и STDERR.
./zz.sh
Теперь начните со стандартного перенаправления :
zz.sh > zfile.txt
В приведенном выше примере "echo" (STDOUT) переходит в файл zfile.формат txt. В то время как" ошибка " (STDERR) отображается на экране.
Вышесказанное то же самое, что и :
zz.sh 1> zfile.txt
Теперь вы можете попробовать обратное и перенаправить" error " STDERR в файл. STDOUT из команды "echo" переходит на экран.
zz.sh 2> zfile.txt
Комбинируя вышеперечисленные два, вы получаете:
zz.sh 1> zfile.txt 2>&1
Объяснение:
- Во-первых, отправьте STDOUT 1 в zfile.формат txt
- Затем отправьте STDERR 2 самому STDOUT 1 (используя указатель &1).
- Поэтому и 1, и 2 помещаются в один и тот же файл (zfile.формат txt)
В конце концов, вы можете упаковать все это в команду nohup и запустить ее в фоновом режиме:
nohup zz.sh 1> zfile.txt 2>&1&