Выполнять команду каждый раз при совпадении регулярного выражения, читая со стандартного ввода, который не имеет EOF
Continuous release then replaces /apps/EXE with a brand new executable.
Это важная часть.
Новый файл выпускается путем создания нового файла (, например. /apps/EXE.tmp.20190907080000), запись содержимого, установка разрешений и владельца и окончательное переименование (2 )в окончательное имя /apps/EXE, замена старого файла.
В результате новый файл имеет новый номер инода (, что фактически означает, что это другой файл.)
И у старого файла был свой собственный индексный дескриптор, который на самом деле по-прежнему примерно равен , даже несмотря на то, что имя файла больше не указывает на него (или больше нет имен файлов, указывающих на этот индексный дескриптор.)
Итак, ключевой момент здесь в том, что когда мы говорим о «файлах» в Linux, мы чаще всего на самом деле говорим об «инодах», поскольку после открытия файла индексный дескриптор является ссылкой, которую мы сохраняем на файл.
Assumption 1: I assume that process P (and anyone else with a file descriptor referencing the old executable) will continue to use the old, in memory /apps/EXE without an issue, and any new process which tries to exec that path will get the new executable.
Верно.
Assumption 2: I assume that if not all pages of the file are mapped into memory, that things will be fine until there is a page fault requiring pages from the file that have been replaced, and probably a segfault will occur?
Неверно. Старый индексный дескриптор все еще существует, поэтому сбои страниц из процесса, использующего старый двоичный файл, по-прежнему смогут найти эти страницы на диске.
Вы можете увидеть некоторые последствия этого, взглянув на символическую ссылку /proc/${pid}/exe(или, что то же самое, lsofвывод )для процесса, выполняющего старый двоичный файл, который будет отображать /app/EXE (deleted), чтобы указать имя больше нет, но индекс все еще существует.
Вы также можете видеть, что дисковое пространство, используемое двоичным файлом, будет освобождено только после того, как процесс умрет (, предполагая, что это единственный процесс с открытым индексным узлом. )Проверьте вывод dfдо и после уничтожения процесса, вы увидите, что он уменьшается на размер того старого двоичного файла, который, как вы думали, больше не существует.
Кстати, это касается не только бинарников, но и любых открытых файлов. Если вы открываете файл в процессе и удаляете файл, файл будет храниться на диске до тех пор, пока этот процесс не закроет файл (или не умрет. )Подобно тому, как жесткие ссылки ведут счетчик количества имен, указывающих на индексный дескриптор на диске, драйвер файловой системы (в ядре Linux )ведет счетчик количества ссылок на этот индексный дескриптор в памяти. и освободит индексный дескриптор с диска только после того, как будут освобождены все ссылки из работающей системы.
Question 1: If you mlock all of the pages of the file with something like vmtouch does that change the scenario
Этот вопрос основан на неверном предположении 2 о том, что отсутствие блокировки страниц приведет к ошибкам сегментации. Это не будет.
Question 2: If /apps/EXE is on a remote NFS, would that make any difference? (I assume not)
Это означает, что работает так же, и в большинстве случаев так оно и есть, но есть некоторые «подводные камни» с NFS.
Иногда вы можете увидеть артефакты удаления файла, который все еще открыт в NFS (, который отображается как скрытый файл в этом каталоге.)
У вас также есть способ назначать номера устройств для экспорта NFS, чтобы гарантировать, что они не будут «перетасованы» при перезагрузке сервера NFS.
Но основная идея та же. Драйвер клиента NFS по-прежнему использует индексные дескрипторы и будет пытаться хранить файлы вокруг (на сервере ), пока на индексный дескриптор все еще ссылаются.
В этом случае похоже, что dbus-monitorуже предоставляет временные метки (в формате времени эпохи + микросекунды ). Таким образом, вам может не понадобиться выполнять dateдля каждого совпадения. Возможно, выражение соответствия можно сузить, например, arg0='Spotify'.
Проверьте вывод этого:
dbus-monitor "
type='method_call',
interface='org.freedesktop.Notifications',
member='Notify',
arg0='Spotify'"
Надеюсь, вы увидите только сообщения dbus, относящиеся к уведомлениям от Spotify. (Невозможно это проверить -Это всего лишь предположение из спецификации dbus). Если это работает, то может подойти следующее:
dbus-monitor --profile "type='method_call',
interface='org.freedesktop.Notifications', member='Notify', arg0='Spotify'" |
gawk -F '\t' '
$NF=="Notify" {
secs = usecs = $2
sub(/^[^.]+/,"",usecs)
print strftime("%Y%m%d-%H%M%S",int(secs),"UTC") usecs
fflush()
}' > timestamp.log
Использование --profileдля выходного формата, так как он кажется более простым для синтаксического анализа, чем вывод по умолчанию --monitor. Передача в GNU awkдля извлечения и форматирования метки времени.