Вы можете использовать экран для запуска команды в фоновом режиме, сохраняя при этом вывод. Используйте что-то вроде
screen -d -m airodump-ng wlan0
. Позже вы можете снова подключиться к экрану, запустив:
screen -r
и остановить вашу команду или сделать что-нибудь еще, что вам нужно сделать.
Если у вас активны несколько экранов, вы можете использовать screen -ls
, чтобы перечислить их все, а затем передать PID того, который вы хотите возобновить, в качестве аргумента screen -r
команду.
Does issuing a reboot command result in systemd ignoring the TimeoutStopSec value?
Нет. Это было бы ужасно, но так не бывает.
РЕДАКТИРОВАТЬ :Некоторые версии systemd выше v233 добавляют JobTimeoutSec=30min
к reboot.target
. Таким образом, в этом случае будет верхний предел (, после которого устройство принудительно перезагрузится ), но он в несколько раз выше, чем значения, которые вы устанавливали до сих пор.
РЕДАКТИРОВАТЬ :По поводу "идея заключалась в том, что система могла быть нетерпеливой и убивала rsyslog, в то время как он все еще сохранял содержимое на диск", сообщение, похоже, было ошибкой в rsyslog.
queue bugfix: file write error message was incorrect #1759 #1759
when a queue was restarted from disk file, it almost always emitted a message claiming "file opened for non-append write, but already contains xxx bytes" This message was wrong and did not indicate a real error condition. The predicate check was incorrect.
Глядя на служебные файлы в Debian 9, обратите внимание, что syslog.socket
(, поставляемый systemd ), содержит DefaultDependencies=no
, а также Before=shutdown.target
и Conflicts=shutdown.target
. Последняя строка прокомментирована Don't allow logging until the very end
. Если у вас не было этих последних двух И rsyslog.service имело DefaultDependencies=no
, демон syslog мог быть повторно -активирован немедленно и вместо этого был убит systemd-shutdown.service
(systemd-shutdown
). systemd-shutdown
использует встроенный -тайм-аут по умолчанию между SIGTERM и SIGKILL, который, я думаю, составляет 90 секунд.