Без nohup в csh фоновое задание все еще выполняется после выхода из ssh
Итак, у вас есть Ubuntu, но с каким-то настраиваемым загрузочным скриптом.
Я предполагаю, что монтирование, скорее всего, запускается каким-то .serviceфайлом в /etc/systemd/system/. (Судя по другим комментариям, похоже, что у вас нет файла .mountдля него -, то есть у вас нет файлаlib-modules.mount).
Но гора может быть начата из ряда других мест. Это также может быть в файле .serviceв /lib/systemd/system, в котором будет много файлов, которые вам придется просмотреть. Они могут запустить mountкосвенно, запустив отдельный скрипт, поэтому быстрый grep mount *.serviceне гарантирует, что вы найдете то, что ищете.
Или, возможно, ваш поставщик задокументировал свои пользовательские модификации встроенного образа «Ubuntu».
Если они этого не сделали, существует набор методов для поиска измененных/созданных файлов, которые не пришли из Ubuntu.
1. .debпакеты, установленные без подходящего источника
Чтобы найти пакеты.deb, которые были установлены напрямую без источника, запустите aptitude search ?obsolete. (Это также покажет, был ли пакет установлен из подходящего источника, но больше не доступен из подходящего источника. Эти пакеты будут считаться «устаревшими» ).
--https://raphaelhertzog.com/2011/02/07/debian-cleanup-tip-2-get-rid-of-obsolete-packages/
Если вы обнаружите подозрительные имена пакетов, вы можете перечислить их файлы. Например. для установленного пакета foo запуститеdpkg-query -L foo). Наоборот,если вы нашли подозрительный файл и хотите исследовать пакет, которому он принадлежит, запустите dpkg-query -s /path/to/file.
2. Пакеты, установленные из подходящего источника, который не называет себя «Ubuntu»
Для поиска пакетов, установленных из включенного apt-источника, который рекламирует себя как что-то отличное от Ubuntu, вы можете запустить aptitude search '?narrow(?installed, !?origin(Ubuntu))!?obsolete'.
Вы также можете проверить предостережение, просмотрев сначала список ваших источников с помощью apt-cache policy. Происхождение источника показано как o=Ubuntu.
--https://raphaelhertzog.com/2011/02/14/debian-cleanup-tip-3-get-rid-of-third-party-packages/
Для сравнения, в версии 16.04 официальные источники по умолчанию могут выглядеть примерно так:
###### Ubuntu Main Repos
deb http://uk.archive.ubuntu.com/ubuntu/ xenial main restricted universe multiverse
###### Ubuntu Update Repos
deb http://uk.archive.ubuntu.com/ubuntu/ xenial-security main restricted universe multiverse
deb http://uk.archive.ubuntu.com/ubuntu/ xenial-updates main restricted universe multiverse
(Трудно найти для них хороший документ, поэтому я взял их из популярной утилитыhttps://repogen.simplylinux.ch).
Или наоборот :для поиска источника (s ), связанного с подозрительным пакетом foo, запуститеapt-cache policy foo
3. Установленные файлы пакетов, которые были (неправильно )модифицированы
Чтобы проверить наличие изменений в файлах из установленных пакетов (, есть очень веские причины не изменять их, но есть возможность ), установите debsumsи запустите debsums -c.
--https://raphaelhertzog.com/2011/02/21/debian-cleanup-tip-4-find-broken-packages-and-reinstall-them/
4. Файлы, которые не были установлены как часть пакета
Можно создать скрипт для поиска файлов, созданных чем-то другим, кроме управляемого пакета apt. Это почти наверняка покажет некоторые ложные тревоги. Я нашел пример скрипта для этой цели:
(
export LC_ALL=C
comm -23 <(find /etc /lib /bin /sbin /usr -type f | sort) \
<(sort -u /var/lib/dpkg/info/*.list)
)
Но если шума слишком много, возможно, лучше попробовать команду cruft, которая, по-видимому, делает то же самое, но знает некоторые файлы, которые можно спокойно игнорировать. cruft -d "/etc /lib /bin /sbin /usr" --ignore "/usr/local".
Список каталогов, которые здесь искали, является чем-то вроде оценочного суждения. Надеемся, что /etc, /usr и /lib должны охватывать сценарии загрузки в большинстве систем Ubuntu, например. любая конфигурация systemd или скрипты sysvinit. Обратите внимание, что в вашем случае вы хотите найти очень ранний скрипт загрузки,что исключает некоторые возможные места. Монтировать /lib/modulesнужно очень рано, чтобы из него можно было загружать модули ядра. Его необходимо смонтировать перед запуском udev.
(С другой стороны, это повышает вероятность того, что в initrd есть какой-то ужасный взлом. Так что, я думаю, стоит обратить внимание на модификации или замену генератора initrd -, кажется, он называетсяinitramfs-tools).
Большое спасибо Рафаэлю Герцогу за написание очень полезной серии сообщений в блогах, на которые есть ссылки в этом ответе.
Нет, фоновая группа процессов (задание )НЕ уничтожается по умолчанию при выходе лидера сеанса (из оболочки )или при отключении управляющего терминала.
Это происходит только в некоторых особых случаях:
(1)Фоновое задание остановлено , и в этом случае оно будет отправлено парой сигналов SIGHUP/ SIGCONTядром . Если сигнал SIGHUPне перехватывается или игнорируется процессом, процесс завершается.
Определением остановленного задания является :любое задание, содержащее остановленный процесс. Процесс , ожидающий блокирующего системного вызова, такого как nanosleep(2)или read(2), НЕ считается остановленным.
(2)Процесс пытается выполнить чтение или запись в терминал, которого больше не существует, и завершает работу (по собственному желанию )из-за ошибок, которые он получает при попытке сделать это.
(3)На самом деле задание является приоритетным . Ядро отправляет сигнал SIGHUPгруппе процессов переднего плана, когда лидер сеанса / управляющий процесс (, т. е. оболочка ), завершается. Управляющий процесс сам сигнализируется SIGHUP, когда его управляющий терминал разрывается, что обычно приводит к его завершению.
Даже команды, начинающиеся с &, на самом деле являются частью группы процессов переднего плана , когда они запускаются из оболочки без управления заданиями (, что в большинстве оболочек --, но не в csh --используется по умолчанию при запуске скриптов и подоболочек).
(4)Вы используете оболочку, такую как bashили zsh, которая изо всех сил пытается отправить сигнал SIGHUPвсем своим заданиям, когда она сама сигнализируется с помощьюSIGHUP(на точку 3. выше, оболочка является управляющим процессом ), или просто когда она выходит из (последнее только по умолчанию в zsh, но не по умолчанию и зависит от опции shopt huponexitв bash ).
Оболочка csh(либо реальная csh, либоtcsh)не имеет такого поведения из bashили zsh. В tcsh(, но НЕ в реальном csh), вы можете запустить команду со встроенной командой hup, чтобы она запускалась при выходе из оболочки:
tcsh% hup sleep 3600 &
tcsh% exit
$ pgrep sleep
[nothing]
(5)Ваша система инициализации делает все возможное, чтобы очистить все прерванные сеансы пользователей. В конфигурации по умолчанию systemd будет сигнализировать обо всех процессах из области с помощью SIGTERM, за которым следует SIGKILLпосле задержки, поэтому nohupНЕ поможет вам с это в любом случае. Кроме того, идея systemd об области не соответствует сеансу процесса Unix, поэтому выполнение команды с setsid(1)также не позволит ей избежать этого.
Вероятно, вы можете изменить поведение systemd, изменив значения по умолчанию для параметров KillUserProcesses=yes, KillMode=control-group, KillSignal=SIGTERMи SendSIGKILL=yes.