Как получить pid до последнего фона app

Для самого фона это приложение создает дочерний процесс и закрывает родительский. Оболочка знает о родительском процессе как о том, который она разветвила перед выполнением самой команды, но она не видит потомков или внуков, которые могли быть порождены этим процессом.

Более простой пример такой фоновой команды:

$ sh -c 'ps -j; sleep 10 &'
  PID  PGID   SID TTY          TIME CMD
 6562  6562 14469 pts/13   00:00:00 sh
 6563  6562 14469 pts/13   00:00:00 ps
14469 14469 14469 pts/13   00:00:00 zsh

Мой zsh знает об этом процессе sh и его группе процессов.

Однако он видит только то, что процесс 6562 завершается. У него нет возможности узнать, что процесс 6562 породил процесс 6563.

$ ps -j
  PID  PGID   SID TTY          TIME CMD
 6564  6562 14469 pts/13   00:00:00 sleep
 6565  6565 14469 pts/13   00:00:00 ps
14469 14469 14469 pts/13   00:00:00 zsh

Однако вы можете видеть, что запущенный процесс sleep также находится в этой группе процессов 6562 (хотя нет ничего, что останавливает команды, запускающие новые группы процессов или даже сеансы (как обычно делают демоны)).

Эти группы процессов создаются только тогда, когда оболочка интерактивна.

Еще вы могли бы сделать следующее:

cmd | cat &
wait

Если процессы, порождаемые cmd, не закрывают свой стандартный вывод, тогда cat не умирает, пока все они не умрут.

Вам даже не нужно проверять, работает ли emacs. emacsclient может запустить демон emacs, если он еще не запущен. От emacsclient (1) :

   -a, --alternate-editor=EDITOR
          if the Emacs server is not running,  run  the  specified  editor
          instead.   This can also be specified via the `ALTERNATE_EDITOR'
          environment variable.  If the  value  of  EDITOR  is  the  empty
          string,  run `emacs --daemon' to start Emacs in daemon mode, and
          try to connect to it.

Я использую псевдоним ge для редактирования файлов, определенный следующим образом:

alias ge="emacsclient -c -n --alternate-editor=\"\""

В большинстве случаев необходимо удалить профиль браузера.

Большинство браузеров имеют команду очистки частных данных. Бывает иногда, что вводится новый механизм места хранения и кнопка «очистить частные данные» не обновляется (например, я, кажется, вспоминаю, что в первые дни HTML5 локального места хранения, были браузеры, которые его реализовывали, но предлагали только кнопку очистки cookie, а не локальное место хранения). Если браузер не доверяет стиранию личных данных, можно удалить весь профиль.

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

Обратите внимание, что удаления всей системы может быть недостаточно, если вы активировали любой вид онлайн-синхронизации (например, через аккаунт Google). В этом случае необходимо удалить или прекратить использование учетной записи в Интернете.

Это невозможно в целом. Это может быть возможно в вашем конкретном случае.

Сразу после выполнения фоновой команды идентификатор процесса может быть обнаружен из родительского . Если вы выполняете команду переднего плана (дочерний объект мастер-программы), а эта команда, в свою очередь, выполняет фоновую команду (внук мастер-программы), мастер-программа не имеет прямой видимости на своем внуке: все, что она знает, это запуск дочернего процесса, который теперь вышел.

Ядро отслеживает child→parent отношения процессов. Можно запустить ps -o ppid = -p $ pid , чтобы увидеть идентификатор процесса родительского процесса процесса с идентификатором $ pid . Ядро не отслеживает бабушку и дедушку процесса. Кроме того, если родитель умирает, процесс принимается init (процесс номер 1), поэтому его идентификатор родительского процесса будет равен 1 с этого момента.

Существует несколько других унаследованных атрибутов процесса, которые можно отслеживать. Однако внук может развестись с любым из этих атрибутов. Если внук предназначен для запуска в качестве демона, он, вероятно, попытается максимально изолировать себя (либо от промежуточного ребенка, либо от самого внука), чтобы он не был привязан к вашему интерактивному сеансу и не рисковал попасть ни в что, происходящее с этим сеансом.

Можно искать процессы в той же группе процессов, что и текущий процесс ( ps -o pgid = )). Это приведет к захвату любого другого процесса, запущенного в той же группе процессов,но, наоборот, пропустите внука, если он работает в собственной группе процессов из-за вызова setpgid или setpgrp в потомке или внуке, что демоны и делают.

Можно искать процессы в том же идентификаторе сеанса, что и текущий процесс ( ps -o sid = ). Это приведет к перехвату любого другого процесса, запущенного в пределах того же идентификатора сеанса, но, наоборот, пропустит внука, если он запускается в собственном сеансе из-за вызова setsid в потомке или внуке, что демоны и делают.

Можно открыть временный файл и найти процессы с открытым файлом ('fuser «$ tmpfile»). Это более надежно, поскольку процессы, запущенные только из части главного процесса, в которой был открыт этот файл, не будут улавливаться другими компонентами главного процесса. Тем не менее, как и другие решения, он пропустит внука, если он или промежуточный потомок закрыл файловые дескрипторы, которые он не использовал, что демоны сделать.

Большинство демонов имеют опцию командной строки, чтобы оставаться на переднем плане. Затем можно запустить демон --foreground & daemon_pid=$! , и вы должны принять меры предосторожности, чтобы избежать захвата демона при выходе из сеанса ( nohup daemon --foreground daemon.log 2 > & 1 & является хорошим началом).

Вы можете получить некоторую информацию, используя strace в скрипте, но он поддерживает работу strace до тех пор, пока подкоманды заканчиваются. Например,

$ strace -b execve -e trace=none -e signal=none -f my-app
Process 21697 attached             <-- is the () &
[pid 21696] +++ exited with 0 +++  <-- is my-app ending
Process 21698 attached             <-- is the sleep 10
Process 21698 detached
test
Process 21702 attached             <-- is the sleep 5
Process 21702 detached
+++ exited with 0 +++

у нас есть идентификаторы суб-оболочки, и команды выполняются там, предполагая, что echo - это встроенная оболочка, поэтому она не отслеживается. -b execve - отсоединение от exec, -f для следования за дочерними элементами, -e для уменьшения вывода на ничего не отслеживая.